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1  INTRODUCTION 

During  the  1950’s  the  phrase  "automatic  programming"  described  the  process 
carried  out  by  assemblers  and  compilers,  i.e.  the  translation  of  a  program  written  in 
oro  language  into  another  where  the  "meaning"  is  preserved  and  the  target  language 
is  interpretable.  Since  then  there  have  been  many  advances  in  programming  languages 
and  their  associated  processors  allowing  the  user  to  specify  at  higher  levels,  or  in 
more  natural  ways,  how  the  computation  should  proceed  and  removing  the  users 
responsibility  for  such  things  as  storage  management,  resource  allocation,  etc. 

In  the  present  project,  we  have  sought  to  develop  methods  that  will  further 
automate  or  augment  the  programming  process  by  generating  programs  over  several 
domains  in  a  suitably  defined  environment  given  a  statement  of  what  they  are  to 
accomplish,  i.e.  programming  by  assertion  rather  than  algorithmically.  We  seek  to 
generate  programs  using  a  statement  of  the  ^esired  program’s  properties  rather  than 
compiling  from  one  detail  specification  of  the  flow  of  control  into  another.  It  is  in  this 
sense  that  we  uso  the  term  automatic  programming.  Automatic  programming  may  be 
further  distinguished  from  compiling  by  its  use  of  a  semantic  model  together  with  a 
deduction  capability.  It  is  to  be  expected,  however,  that  as  progress  is  made  in 
automata  program  generation  that  research  in  compilation  will  be  benefited. 

As  the  field  of  Artificial  Intelligence  has  matured,  problem  solving  techniques 
have  been  developed  that  have  allowed  us  to  seriously  consider  building  automatic 
programming  system.  Some  very  influential  ideas  came  from  the  Heuristic  Compiler 
[Simon  1963]  and  the  GPS  [Newell  and  Simon  1963]  projects,  i.e.  the  notion  of  building 
up  a  program  in  a  state-space  tree  search  using  a  problem  reduction  procedure.  This 
is  cemainly  basic,  almost  subconsciously  so,  to  the  present  project  and  has  been 
widely  used  by  others. 
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Ounng  the  '  960's  much  of  the  theory  of  problem  solving  was  associated  w,th 
Iree  or  graph  searching  methods.  Well  known  techniques  for  restricting  the  search  by 
osmg  evaluation  functions,  -mm, maxing",  the  *-/S  method,  etc.  may  be  found  ,n  [Nilsson 
1971].  [Samuel  1963],  Later  automatic  programming  work,  still  depending  heavily  on 
search  strategies,  sougnt  to  reprasent  the  domain  semantics  and  carry  out  the 
deduction  in  first  order  logic  using  the  principle  ol  resolution  [Green  1969],  [Waldinger 
and  Lee  1969J  A  more  powerful  tgenerated  deeper  proofs)  general  deduction  system 
combining  resolution,  equality  and  algebraic  simplification  was  reported  ,n  [Allen  and 
Luckham  1970],  A  great  deal  of  the  systems’  efforts  were  spent  in  search  because 
most  facts  were  uniformly  represented  as  axioms  in  clause  form  and  the  search 
strategies  were  largely  syntactic.  Greater  efficiency  was  gained  in  a  system  built  by 

separating  the  heurisfic  search  from  the  deduction  and  employing  the  GPS  paradigm 
(Fikes  and  Nilsson  1971]. 

The  difficulty  in  these  systems  of  using  facts  to  guide  the  search  has  prevented 
them  from  solving  hard  for  humans)  problems  or  generating  complex  programs.  It  has 
become  clear  that  in  addition  to  a  manageable  basic  problem  solving  method, 
knowledge,  both  general  and  domain  specific,  must  be  provided  in  a  functionally  useful 
way  to  enable  the  sysiem  to  find  a  solution.  During  the  last  two  years  language 
systems  that  allow  the  user  to  easily  embed  knowledge  at  all  levels  have  been 
oeveioped.  Other  useful  lectures  are  pattern  matching,  pattern  evoked  procedures, 
flexible  control  structures,  multiple  contexts  and  processes  [Hewitt  1S69J  [Sussman 
and  McDermott  1972],  [Kulifson  et  at.  1972],  [Feldman  c-t  at.  1972],  [Tesler,  Enea  and 
Smith  1973J.  Our  use  of  some  ol  these  features  will  bo  described  in  later  sections. 
Taking  advantage  of  some  of  these  features  and  refining  the  notion  ol  semantics  was  a 
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natural  language  understanding  system  reported  in  [Winograd  1971],  Other  automatic 
programming  or  debugging  systems  are  [Deutsch  1973]  and  [Sussman  1973].  Some 
general  descriptions  and  useful  classifications  of  the  components  of  an  automatic 
programming  system  have  been  g;ven  in  [Balzer  1972].  The  closure  of  all  these 
capabilities  is  yet  to  be  fully  exploited  in  a  problem  solving  or  automatic  programming 
system. 

Procedural  Knowledge  may  be  distinguished  from  declarative  in  that  the 
information  content  is  expressed  within  the  flow  of  control  of  a  computation  (in  the 
general  sense)  sequence,  i.e.  the  data  from  which  useful  information  may  be  extracted 
is  the  program  itself.  This  is  probably  the  most  efficient  information  access  scheme  of 
all  An  intelligent  system  in  which  all  information  is  expressed  procedurally  will  rely 
more  heavily  (perhaps  totally)  on  tne  current  state  of  computation  to  determine  its 
future  behaviour  than  a  system  utilizing  declarative  facts  and  also  be,  necessarily, 
more  dependent  on  the  ordering  of  its  knowledge. 

However,  the  distinction  begins  to  blur  when  we  consider  how  a  system  may 
effectively  utilize  declarative  information  and  how  given  a  general  computational  model, 
e.g.  problem  reduction  algorithm  as  in  our  system,  declarative  facts  may  be  translated 
into  procedures.  Another  example  of  this  is  the  "questionnaire  programming"  approach 
for  customizing  business  application  systems.  Progress  has  been  made  in  defining 
model  specification  languages  having  procedural  and  non-procedural  components 
[Hewitt  1969], [Martin  1973],  [Hammer,  Howe  and  Wladawsky  1974].  Even  a  resolution 
based  theorem  prover  with  an  appropriate  protocol  language  (tne  procedural  pari)  can 
efficiently  use  its  knowledge  to  solve  a  problem  [Allen  and  Luckham  1973],  [Stickel 
1974]. 
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Research  in  verifying  existing  programs  [Floyd  1967],  [King  1969],  [Katz  and 
Manna  19/3],  [Milner  1972]  has  contributed  to  our  understanding  of  programs  and  we 
have  found  (not  surprisingly)  that  the  Kinds  of  facts  required  to  verify  progr?ms  are 
not  distinct  from  those  required  for  the  synthesis  of  correct  programs.  Progress  has 
also  been  made  in  defining  axioms  and  rules  of  inference  for  the  semantics  of 
programming  languages  [Hoare  1969]  and  in  particular  with  respect  to  the 
programming  language  PASCAL  [Hoare  and  Wirth  1972].  This  Logic  of  Programs  has 
been  further  developed  and  used  as  a  basis  for  a  verification  system  in  [Igarashi, 
London  and  Luckham  1973],  As  a  logical  basis  for  an  automatic  programm  ng  system 
this  logic  is  especially  convenient  since  ihe  rules  are  intuitively  clear,  the  system 
operation  may  be  easily  formalized  and  correctness  considered,  and  rule  applications 
proceed  in  natural  (for  humans)  steps. 

The  objectives  of  the  present  project  have  been  to  extend  the  theory  of 
semantic  definitions  to  describe  automatic  programming  problems  and  to  design  and 
implement  a  system  that  uses  this  information  in  a  functionally  useful  way  to 
atuomatically,  or  interactively,  generate  programs. 

The  particular  formalism  developed  to  define  the  programming  environment  (or 
FRAME)  called  the  FRAME  language,  will  be  shown  to  have  elements  whose  form 
corresponds  to  statements  in  the  Logic  of  Program^.  It  is  based  on  a  typed,  free 
variable  first  oroer  logic  in  which  statements  may  have  truth  values  of  either  true, 
false  or  undetermined.  The  frame  language  consists  of  primitive  procedures,  logical 
axioms,  definitions,  iterative  schemes  and  additional  information  about  these  rules  and 
the  relations  in  them.  Other  rules  of  program  composition,  referred  to  as  standard 
rules  (described  in  Section  2),  are  built  into  the  system  and  needn’t  be  specified  for 
each  frame,  i.e.  composition  rule,  conditional  rule,  etc. 


INTRODUCTION 


5 


The  frame  language  may  be  viewed  as  an  intermediate  level  model  specification 
language  that  is  non-procedural  and  domain  independent.  It  was  motivated  by 
observing  that  in  the  general  deduction  systems  previously  mentioned  there  was  more 
information  in  the  axioms  than  was  being  used  operationally,  i.e  there  were  different 
kinds  of  axioms  and  relations  (see  Section  3)  that  should  be  treated  differently  by  the 
system.  For  example  the  truth  value  of  some  relations  are  functions  of  the  state,  or 
FLUENT  [McCarthy  and  Hayes  1969]  and  some  are  NON-FLUENT.  For  efficiency  some 
relations  could  be  handled  in  a  two-valued  logic,  i.e.  TOTAL,  and  others  require  the 
generality  of  a  three-valued  logic.  Also  search  guidance  information  should  be 
provided  (embedded)  at  all  levels.  For  example  compared  with  a  resolution  based 
system  we  would  like  to  choose  the  best  "set-of-support"  at  each  level  of  deduction. 
We  also  wanted  a  language  extendible  to,  or  translatable  from  a  higher  level,  more 
natural  input  language,  e.g.  recursion  equations  for  the  Fibonacci  series  example  in 
Section  3  and  the  factorial  example  in  Section  6.  A  frame  actually  describes 
programming  techniques,  the  extensiveness  of  which  determine  the  complexity  of 
programs  produceable  using  it. 

Given  a  frame,  F,  a  problem  for  program  construction  may  be  stated  as  a  pair 
<I’G>,  Where  1  is  a"  j"Put  assertion  and  G  is  an  output  assertion.  The  program 
generation  task  is  to  construct  a  program  A  such  that  I{A}I\  where  I’^G.  This  process 
may  be  viewed  as  a  search  in  the  logic  of  programs  for  a  proof  that  the  generated 
program  satisfies  the  given  input-output  assertions.  A  solution  to  the  problem  is  the 
sequence  of  rules  of  inference  and  axioms  used  in  the  proof.  This  view  allows  us  to 
show  correctness  of  the  formal  methods  for  program  construction.  The  correctness  of 
the  program  actually  generated  by  the  system  will  depend  on  our  ability  to  implement 


6 


INTRODUCTION 


the  formal  algorithm.  The  solution,  or  output,  programs  are  written  in  a  subset  of 
ALGOL  containing  procedure  calls,  assignments,  while  loops  and  conditional  statements. 
Program  construction  is  by  simulated  execution  where  iterative  rules  with  associated 
output  assertions  are  used  to  update  the  computation  model  for  simulating  the 
execution  of  a  loop. 

Tha  application  domains  studied  and  in  which  programs  have  been  generated  are 
numerical  computation,  symbolic  manipulation,  guidance  procedures  for  a  robot, 
assembly  and  repair  of  machinery,  and  sequential  planning  together  with  generating 
contingency  plans  for  a  wide-  range  of  decision  making  problems.  Though  we  have 
here  pursued  a  course  of  developing  one  system  then  applying  it  to  several  domains 
by  merely  changing  the  content  of  the  frame  definitions,  it  is  expected  that  for 
practical  performance,  the  form  of  the  system  definitions  will  depend  on  the  domain. 
For  example  this  is  currently  happening  in  researcn  attempting  to  appiy  this  system  to 
automating  data  base  management  tasks  [Gerritsen  1974]  and  automated  repair  of 
machinery  [Luckham  and  buchanan  1974J. 

The  rules  of  inference,  axioms  and  other  logical  facts  expressed  in  the  frame 
definitions  are  translated  into  a  backtrack  problem  reduction  system  augmented  by 
special  search  procedures  using  these  facts.  The  target  language  of  this  translation  is 
LISP  using  primitives  and  backtracking  facilities  of  Micro-Planner  [Hewitt  1971], 
[Sussman  and  Winograd  1972],  This  subgoaling  system  recursively  applies  to  a  goal 

the  rules  of  the  frame  to  generate  subgoals  whose  solution  imply  a  solution  to  the 
original  goal. 

As  an  auxilary  to  the  subgoaling  system  is  an  ADVICE  system  with  an  associated 
language  that  allows  the  user  to  guide  the  search,  modify  the  frame,  restrict  rule 
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applications  and  receive  interactive  feed-back  during  program  construction.  This  is 
described  in  Section  3. 


Figure  1.  Main  System  Components 


The  main  components  of  the  system  are  shown  in  figure  1.  The  user  may 
interactively  specify  a  frame  and  provide  some  initial  advice  (model  acquisition  phase). 
This  is  eventually  iranslated  into  a  subgoal:ng  problem  solver  to  which  a  problem  may 
be  given,  i.e.  a  goal  which  the  problem  solver  seeks  to  achieve  using  the  rules  of  the 
frame  (program  generation  phase).  If  a  solution  program  is  constructed,  the  user  may 
incrementally  extend  it,  i.e.  pose  another  problem  which  takes  the  output  assertion  of 
the  current  solution  program  ss  its  input  assertion.  The  user  may  also  optimize  it,  or 
generalize  it  and  place  it  in  the  program  library  for  future  inclusion  in  a  generated 
program.  If  the  program  contains  conditional  calls  to  as  yet  ungonerated  procedures 
(see  Section  5),  these  subpioolems  may  be  attempted.  Subproblems  may  also  arise  by 
declaring  some  primitive  procedures  defined  in  the  frame  to  be  assumptions  to  br 
expanded  into  concrete  programs.  This  provides  a  rather  rudimentary,  at  this  time, 
interactive  structured  program  development  facility. 
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1.1  CONTRIBUTIONS 

Some  of  'he  areas  of  wor*  along  which  progress  has  been  made  and 
contributions  to  the  field  may  be  noted  are  as  follows: 

(1)  Extending  the  theory  of  semantic  definitions  for  defin.ng  semantics  of  programming 
languages  to  define  automatic  program  generation  environments.  A  relation  has  also 
become  more  clear  betwee:  the  kind  of  assertions  needed  to  verify  programs  and 
those  required  to  syntnesize  correct  programs,  e.g.  compare  loop  invariants  used  in 
our  system  with  inductive  assertions  for  program  verification. 

<2)  A  prototype  system  has  been  developed  that  is  useful  in  a  study  to  determine  the 
feasibility  of  building  an  automatic  programming  system  to  augment  the  programmer  in 
the  following  ways: 

(a)  Automatic  or  interactive  generation  of  possible  solution  programs  for 
application  domains  suitably  described, 

fb)  The  usefulness  of  an  automated  system  to  handle  bookkeeping 
details, check  consistency,  applicability,  etc., 

(t)  The  feasability  of  an  interactive  structured  development  system, 

(d)  The  feasability  of  interactively  building  up  complex  programs  by  allowing 
incremental  program  extension,  library  access,  structured  development, 
and  contingency  planning. 

(3)  A  demonstration  is  made  that  declarative  facts  can  be  incorporated(translated)  into 

an  efficient  problem  solving  search  procedure  which  uses  these  facts  at  all  levels  of 
search. 

(A)  A  typed,  free  variable  first-order  logic  in  which  statements  may  have  truth  values 
of  true,  false,  or  undetermined  has  been  shown  to  be  a  natural  logical  basis  for 
automatically  generating  conditional  statements  in  a  program. 
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(5)  The  iterative  rule  computation  scheme  has  a  correspondence  to  the  principal  of 
mathematical  induction  and  is  a  useful  way  to  represent  loop  structure  for  a  piogram 
to  be  generated. 

To  the  nagging  question  that  it  may  be  as  hard  (or  harde,)  to  specify  a  frame  as 
it  is  to  write  the  program,  the  following  answers  may  be  given: 

(1)  Yes,  but  we  are  learning  how  to  program  by  assertion,  and  develop  defining 
formalisms  and  methods  for  efficiently  manipulating  facts  and  rules. 

(2)  A  frame  may  contain  many  atomic  units  of  information  whose  interaction  when 
faced  with  a  novel  goal  is  not  easily  predictable.  For  example  the  robotics  frame 
defined  in  Section  7  may  be  used  to  generate  many  different  programs. 

(3)  An  interactive  facility  for  constructing  programs  with  the  extendable  features 
mentioned  above  can  potentially  augment  the  human  programmer. 

(4)  Experience  with  our  frame  language  has  been  helpful  in  investigating  the  basic 
information  required  to  construct  programs,  now  the  task  of  raising  the  level  of 
lanr uage  interaction  to  a  more  natural  (and  useful)  level  will  be  aided. 
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1.2  EXTENSIONS 

The  following  specific  research  problems  ere  suB6esleb  as  natural  exlens.ons  of 
this  work  (i.e.  problems  we  didn’t  solve;: 

(the  -eader  may  want  to  scan  these  now  then  come  back  to  them  alter  rradtng 
further) 

(1)  In  the  area  of  conditional  statement  generation: 

(a)  introduce  probabilistic  decision  theory  to  determine  preference  amonC 

cominger,,./  problems. 

(b)  Develop  criteria  for  recognizing  equivalent  or  similar  subproblems. 

<0  065,60  °  more  tlexib,e  mechanism  for  managing  scope,  program  structure 
and  contingency  goal  selection.  Since  there  is  no  reason  to  prefer  the 

trunk  path,  the  structure  of  the  output  program  should  not  be  fixed 
from  that  point  on. 

(d)  Compute  completely  correct  input-output  assertions  for  programs  having 
arbitrary  nesting  of  conditional  statements. 

(2)  In  the  area  of  automating  structured  programming: 

(a)  Develop  a  human  engineered  interactive  system.  Regardless  of  how  the 

"theology"  says  we  should  program,  there  is  something  basic  to  the 
human  condition  about  how  we  do  program  and  style  improvement  must 
be  made  within  that  framework. 

(b)  Develoo  techniques  for  managing  side  effects. 

(c)  Do  lookahead  or  design  a  bottom-up,  outside-in,  etc.  component. 

(3>  In  the  area  of  generating  programs  with  looping  structure: 

(a)  Implement  some  form  of  the  recursion  rule[Hoare  15*69]. 
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(b)  Develop  efficient  and  more  complete  methods  for  updating  the  otate 

consistently.  Design  criteria  for  detecting  inconsistent  states  and 
prevent  them  from  invalidating  the  program. 

(c)  Generata  while  loops  but  reduce  tho  information  that  the  user  must 

provide.  For  example,  in  iterative  rules  the  systt.-*  shap'd  reasonably 
deduce  the  conti  ol  test  or  output  assertion. 

(d)  Bu  Id  in  the  iterative  rule  (analogous  to  the  way  the  conditional  rule  is 

built  in).  This  is  really  trying  to  do  induction.  We  would  like  the  ability 
to  analyze  a  computation  trace,  recognize  loop  structure  and  generate  a 
while  loop. 

(4)  A  higher  level  or  more  comprehensive  input  language  should  be  developed.  It  will 
probably  be  domain  dependent. 

(5)  Explore  the  implications  of  various  logics  for  programs  as  a  basis  for  automatic 

programming.  In  [McCarthy  and  Hayes  1969]  various  logics  are  discussed  for 
intelligent  systems. 

(6)  Strive  to  free  the  problem  solver  from  being  so  dependent  on  the  ordering  of  goals 

in  a  condition  to  be  achieved  or  the  ordering  of  applicable  rules.  Develop  reordering 
strategies,  lookahead,  etc. 

(7)  In  the  area  of  parallel  processes: 

(a)  Generate  programs  for  parallel  machines. 

(b)  Develop  criteria  for  splitting  up  a  generated  sequential  program  into 

subtasks  for  cooperating  sequential  processes. 

(8)  Exploit  multiple  processes  and  multiple  contexts  to  increase  the  power  of  the 
problem  solvers,  e.g.  a  better  answer  to  the  question  of  why  a  node  failed  could  yield 
automatic  correction. 
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(9)  Organ, ze  a  library  of  gene  aled  programs  and  develop  strategies  for  its  access. 
<101  Study  the  proolem  of  val,dat,on  of  program  specification.  Determ, ne  cons.slency 


and  adequacy  of  a  Programming  model.  Prove  proport.es  of  the  family  of  programs 
constructable  from  the  same  frame.  Sfudy  the  invariants  of  data  structure  under 
app.icat.on  of  a  tam.ly  of  programs,  e  g.  do  they  modify  the  tree  orderedness  of  a  label 


tabie. 
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1.3  COMMENTS  ON  THE  FUTURE  OF  AUTOMATIC  PROGRAMMING 

The  need  for  some  automation  in  the  task  of  software  production  is  becoming 
increasingly  clear.  System  are  getting  bigger  and  more  complex  which  has  caused 
maintenance  cost  to  rise  (It  is  now  50  per  cent  of  the  programming  budget).  Software 
costs  too  mucn,  it  isn’t  reliable,  takes  too  long  to  develop  and  its  difficult  to  modify  or 
fix.  Programming  has  not  attained  the  maturity  to  dovelup  standard  engineering 
practices  witn  their  attendant  reliability  that  otter  disciplines  have.  Research  in 

automatic  programming  seeks  to  understand  the  nature  of  the  task  and  thereby 
improve  oroduciion. 

There  are  many  d  tensions  along  which  automatic  programming  will  progress. 
There  is  the  theoretical  dimension  whicn  implies  gaining  a  more  fundamental 
understanding  of  the  meaning  of  programs  and  developing  descriptive  and  useful  logics 
for  automatic  programming  problems  that  permit  a  rigorous  investigation  of  the 
properties  of  a  program.  Along  the  pragmatic  dimension,  we  will  be  interested  in 
augmenting  current  practice  with  state  of  the  art  techniques.  There  is  also  the 
heuristic  dimension  which  contains  the  multitude  of  ideas,  systems  and  ad  hoc  notions 
for  which  there  is  no  good  logical  description  nor  is  there  any  current  practical 
application,  but  through  them  we  gain  understanding  into  the  nature  of  the  problem, 
the  following  are  a  list  of  rather  random  comments  on  the  future  of  automatic 
programming  based  on  our  experience. 

(i)  More  emphasis  will  be  placed  on  higher  level  descriptive  formalisms  and 
programming  languages  to  define  programming  environments.  The  level  will  be  raised 
to  accomodate  the  non-programmer  as  we, I  as  to  ease  the  job  of  the  professional. 
Some  of  these  advances  will  require  major  breakthroughs  in  Artificial  Intelligence,  e.g. 
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dynamic  acquisition  of  models,  recognition  of  incomplete  or  inconsistent  models,  or 
further  development  in  representing  knowlege  in  a  functionally  useful  way. 

(2)  Larger  Software  facilities  will  be  developed  for  systems  to  contain  more  facts. 
Deduction  will  be  efficiently  encoded  (perhaps  specialized  as  in  the  theorem  prover 
over  the  integers  in  [King  and  Floyd  1970]). 

(3)  Specialized  domain  application  systems  will  be  built  that  will  rival  human  abilities 
(perhaps  the  standard  five  year  time  estimate  will  do).  Compared  with  the  present 
system  these  will  require  new  kinds  of  built  in  facts,  different  advice  needs  and 
computation  schemes.  To  make  real  progress  trar  rerring  technology  developed  in  one 
system  to  the  improvement  of  another  in  perhaps  a  different  domain  we  must  focus  on 
the  methods  used  to  embed  knowledge  or  define  the  environment  rather  than  just 
loading  the  system  with  facts  and  ad  hoc  tricks  or  using  a  human  interface  that  only  its 
creator  can  understand.  The  field  is  so  young  that  too  much  time  shouldn’t  bo  spent 
hand  tuning  a  system  once  the  basic  methods  are  exploited. 

(4)  There  are  some  short  term  payoffs  (within  5  years)  for  augmenting  programmers, 
e.g.  better  interactive  debugging  systems,  languages  permitting  user  assertions  to  be 
checked  and  better  optimizers.  Within  a  narrow  domain  present  technology  can  yield 
good  performance.  Automatic  programming  will  not  replace  the  programmer  but  will 
raise  the  educational  level  for  those  who  would  do  computer  assisted  program 
construction.  With  respect  to  program  synthesis  we  should  strive  to  generate 
programs  of  the  type  that  people  understand  and  can  write  with  some  effort  so  that 
program  synthesis  does  not  get  completely  lost  in  futuristic  AI  research.  Within 
current  technology  the  size  of  the  generateable  programs  will  be  small  (one  page)  and 
complexity  will  be  gained  by  combining  and  extending  them  with  interactive  aids. 
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(5)  INTERACTIVE  systems  will  bo  developed  that  will  do  mundane  logical  chocking, 
answering  "what  if"  questions,  and  building  up  complex  programs  modularly  such  that 
the  system  will  only  have  to  focus  on  o*e  small  problem  at  a  time. 

(6)  Within  the  forseeable  future  final  production  level  systpns  will  not  be  automatically 
produced  but  the  ability  to  produce  prototype  systems  quickly  to  test  design  ideas  will 
be  a  significant  aid  to  software  production. 
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In  Section  2  a  short  description  of  the  logic  of  programs  is  given  in  which  the 
frame  definitions  and  program  construction  rules  are  formulated.  A  simple  example  is 
given  that  illustrates  how  a  problem  is  formulated  and  the  meaning  of  a  solution. 
Section  J  describes  the  frame  definition  language,  advice  language  and  output  prograrr 
language.  In  Section  4  the  systems  use  of  information  during  the  problem  solving 
process  is  described.  Sections  5  and  6  present  the  system  methods  for  generating 
conditional  statements  and  iterative  loops  respectively.  Section  7  descibes  the 
programming  aids  provided  in  the  system  for  the  user  to  interactively  generate  more 
complex  programs.  In  Section  8  is  given  tne  formal  program  generation  algorithm  and  a 
description  of  the  proof  of  its  correctness.  Section  9  is  intended  to  document  the 
system  implementation  to  the  level  that  would  be  reasonably  useful  in  designing  an 
expanded  system.  Illustrative  examples  of  frames  and  generated  programs  are  given  in 
Sections  3,5,  G,7  and  appendix  A.  Appendix  U  coniains  a  complete  interactive  session. 
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In  this  section  we  will  briefly  describe  how  frames  can  be  formulated  within  the 

Logic  of  Programs.  Later  sections  will  expand  on  the  frame  formalism  and  its  use. 

Program  generation  may  then  be  viewed  as  a  search  for  a  proof  within  the  Logic  of 

Programs  that  the  generated  program  satisfies  its  input-output  assertions.  In  Section 

8  the  formal  algorithm  will  be  given  and  correctness  of  solutions  considered. 

A  distinction  should  be  made  between  the  problem  solving  algorithms  and  their 

implementation  in  any  particular  system  where  an  implemented  system  must  fall  short 

of  the  formal  algorithm.  For  example  program  correctness  will  depend  upon 

maintaining  consistency  of  each  state  occuring  during  program  construction,  yet  in 

general  the  task  of  determ  ning  state  consistency  is  undecidable.  However  limited 

deduction  is  carried  out  and  special  mechanisms  to  detect  common  inconsistencies,  e.g. 

single  valuedness  of  program  variable;,  . re  implemented. 

NOTATION:  x,y,z,u,v,w...variables, 

X,Y,Z,...  lists  of  variables, 

f,g,h....  functions, 

s,t...  functional  terms, 

G,I,P,Q,R,S,...  Eoolean  expressions  (essentially  formulas  of  first  order 
logic  with  standard  functions  and  predicates  for  equality, 
numbers,  lists  and  other  data  types), 

P(X)  denotes  the  formula  obtained  by  replacing  each  free  variable  in  P 
by  a  new  variable  from  X, 

(3X)P(X)  denotes  existential  quantification  over  all  X-varicbles  in  P(X), 

A,B,C,...  programs  and  program  parts  in  an  Mlgol-like  plan  language 
(details  in  Section  3), 

p,q,...  procedure  names, 

oC,/3,X,...  substitutions  of  terms  for  variables,  also  denoted  by  (<x«-t>). 

P(t)  denotes  the  result  of  replacing  x  by  t  everywhere  in  P(x). 

oC/S  denotes  the  COMPOSITION  of  u  and  (i\  E u/i  =(E*)/3  for  all 
expressions  E. 
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We  assume  the  existence  of  a  fixed  arbitrary  ordering  of  literals  defined  in  the 
frame  (atoms  and  negations  ol  atoms)  which  is  simply  used  as  a  computational  aid  (or 

describing  and  implementing  the  rule  of  invariance  defined  in  Section  2.2  and  not  for 
any  heuristic  advantage. 


LOGICAL  BASIS  FOR  SEMANTIC  DEFINITIONS 


19 


2.1  LOGIC  OF  PROGRAMS 

We  review  briefly  the  elements  of  an  inference  system  for  proving  properties  of 

programs  [Hoare  1969].  This  description  is  taken  from  [Igarashi,  London,  Luckham 
1973], 

STATEMENTS  of  the  logic  are  of  three  kinds: 

(i)  Boolean  expressions,  (henceforth  often  called  ASSERTIONS) 

(ii)  statements  of  the  form  P{A)Q  where  P,Q  are  Boolean  expressions  and  A  is  a 
program  or  program  part. 

P{A}Q  means  "if  P  is  true  of  the  input  state  and  A  halts  (or  halts  normally  in 

the  case  that  A  contains  a  GO  TO  to  a  label  not  in  A)  then  Q  is  true  of  tne 
output  state". 

(iii)  Procedure  declarations,  p  PROC  «  where  p  is  a  procedure  name  and  K  is  a 
program  (the  body  of  p). 

A  RULE  OF  INFERENCE  is  a  transformation  rule  from  the  conjunction  of  a  set  of 

statements  (premisses,  say  H,  _,H,  )  to  a  statement  (conclusion,  say  K)  of  hind  (ii). 
Such  rules  are  denoted  by 

Hi  .-A 
K 

The  concept  of  PROOF  in  the  logic  of  programs  is  defined  in  the  usual  way  as  a 
sequence  of  statements  that  are  either  axioms  or  obtained  from  previous  members  of 
the  sequence  by  a  rule.  A  proof  sequence  is  a  proof  of  its  end  statement. 

NOTATION:  We  use  H  ||-  K  to  denote  that  K  can  be  proved  by  assuming  H.  H  |-  K 
denotes  the  same  thing  for  f.rst  order  logic.  It  is  sometimes  helpful  to  denote 
statements  that  are  problems  or  subproblems  for  the  program  generator  to  solve  by 

P{?}Q. 


20 


LOGICAL  BASIS  FOR  SEMANTIC  DEFINITIONS 


2.2  FRAME  RULES 

The  RULES  in  a  frame  F  are  of  three  kinds: 

(a)  PROCEDURES  transform  slates  ,nto  states  and  are  expressed  as  statements  in 
the  logic  of  programs. 

(b)  SCHtMtS  are  methods  for  constructing  programs  and  are  expresed  as  rules  of 
inference  in  the  logic  of  programs. 

(c)  RELATIONAL  LAWS:  definitions  and  axioms  which  hold  in  alt  states  and  serve  to 
complete"  incomplete  state  descriptions  by  permitting  first  order  deduction  of 

other  elements  of  a  state  from  those  given. 

Given  a  frame  F  a  problem  for  program  construction  may  be  stated  as  a  pair 
<I,G>,  where  I  is  an  input  assertion  (or  initial  state)  and  G  is  the  output  assertion  (or 
goal  that  must  be  true  in  the  output  state).  The  program  construction  task  is  to 
construct  a  program  A  such  that  IfAjf,  where  foG.  A  solution  is  the  sequence  of  rules 
of  F  used  in  the  construction  of  the  solution  program  A. 

NOTATION  and  RESTRICTIONS:  0  u  F  o  R  denotes  that  R  is  a  logical  consequence  of  Q 
and  the  axioms  of  F.  Assertions  describing  states  are  denoted  by  I,r,...,G1GV..  These 
assertions  tbut  not  the  assertions  in  rule  definitions)  are  restricted  to  be  conjunctions 
of  atomic  assertions.  We  write  R,I  to  denote  that  R  is  a  conjunct  in  I.  L(F)  denotes  the 
logic  of  F,i.e.  the  set  of  consequences  of  the  rules  of  F.  Substitutions  «  do  not 
replace  any  variable  that  occurs  in  the  initial  state  I.  Expressions,  all  of  whose 
variables  occur  in  the  initial  state  are  called  "fully  instantiated". 

STANDARD  FRAME  RULES:  A  set  of  standard  rules  are  assumed  to  be  par.  of  every 

frame.  These  are  rules  implemented  in  the  program  construction  methods  of  the 
problem  solving  algorithm: 


RO.  Assignment  Mxioms: 
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(i)  Simple  Assignment:  P(t'{>  ^t}P(x) 

<ii)  Conditional  Assignment:  (3Z)P(Z){IF  P(W)  THEN  Y«-W}P(Y) 
-'(3Z)P(Z)aQ(Y){IF  P(W)  THEN  Y«-W}Q(Y) 


where  Y-variables  in  P(Y)  do  not  occur  in  P(W),  W-variables  are 
special  variables  ocurring  only  in  conditional  assignments,  and  Y-W 

sequence  of  simP,e  assignments  between  members  of  Y 
and  W  that  occur  in  the  same  argument  positions  in  P(Y)  and  P(W). 


Rl.  Rule  of  Consequence:  P:>Q,Q{A}R  P{A}Q,QoR 


P{A}R  P{A}R 


R2.  Rule  of  Composition:  P{A}Q,Q{B}R 


P{AiB}R 


r<3.  Rule  of  Invariance:  if  P{A}Q  and  I  u  F  d  P  then  I{A}Inv(Q,I) 
where  if  Hi,R2i„iRn  are  the  conjuncts  of  I 
in  the  fixed  order,  then  Ie  «•  Q, 
for  0<m<n,  Im^  ■=  Im  a  Rm  if  -{lm  uFs  -R„) 

Wt  =  Im  otherwise, 
and  Inv(Q.I)  =  In. 


R4.  Change  of  Variables:  P(x){A(x)}Q(x)  where  y  is  not  a 

. .  special  variable. 

Hy){M(y)}Q(y) 

R5,  Conditional  Rule:  PaQ{A}R,  Pa-Q{B}R 


P{IF  Q  THEN  A  ELSE  B}R 


R6.  Undetermined  values:  If  I’{?}G  c.nnot  be  solved  and 
-(I’uF  d  •’G)  then  G  is  UNDETERMINED  in  I’. 


STANDARD  RULES 


REMARKS;  (.)  The  axioms  RO(ii)  define  the  semantics  of  conditional  assignment 
statements  used  primary  in  the  system  during  the  assembly  ut  while  loups  The 
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that  if"  1  W'  !*IF  statement  is  interpreted  as  a  call  to  a  Boolean  procedure 
true’  nsuccessful;  WHl  bmd  the  ^/-parameters  to  values  from  the  state  that  make  it 

such  conditinna|en  ,0n  'S  t0.  reg.ard  W-variables  as  "special  variables"  only  occurring  in 
,d  assignments.  An  alternative  would  be  to  define  a  typed  procedure  for 

asTgnmen'To  '"Z  ^  ,he  ^P-Priate^value  5or  Xen 

""  C0ndi,i0r’al  — «■*  «» 

stateTmLtrneh  °f  tmea"s  that  durin*  a  state  transformation  and  a  new 

statement  0  becomes  true  in  I  that  the  function  Inv(Q,I)  will  return  Q  union  these  facts 

ml  that  do  not  contradict  Q.  We  therefore  do  not  need  "frame  axioms"  to  handle  the 

Haves  l969]  as  ,he  resoiu,ion  p"»« 


(ill)  The  rule  of  undetermined 
conditional  statements  (Section  5). 


values  guides  the  systems  decision 


to  generate 


INPUT  FRAME  RU!  ES:  In  addition  to  the  standard  rules,  a  frame  may  contain  rules  of 
the  following  types  (these  constitute  the  user  defined  elements  of  the  frame): 

St.  Primitive  procedures  (or  operators):  the  rule  defining  procedure  p  is  of  the  form 

PIpIO.  The  assertions  P  and  Q  are  the  pre-  and  post-conditions  of  p.  p  must  contain  a 
procedure  name  and  parameter  list. 

S2.  Iterative  rules:  an  iterative  rule  definition  containing  the  Boolean  expressions 

P(basis),  Q(loop  invariant),  R(iteration  step  goal),  Ucor.trol  test)  and  Glrule  goal)  Is  e 
rule  of  inference  of  the  form: 


(a)  P  ,  |-  Q,  QaL{MR,  R{??)Qv-L 

P{whilu  L  do  ?;??jG 

where  the  free  vanables  of  R  and  L  occur  in  Q.  Such  rules  are  permitted  not  to 
contain  P  or  l, in  which  case  they  correspond  to  inferences  of  the  form: 

(b)  Q,  Qa-<G{?}R,  R{??}QvG 
Qfwhile  -G  do  ?;??}G 

S3.  Definitions.  A  definition  of  G  in  terms  of  P  is  a  logical  equivalence  |-  P.G. 

SA.  Axioms.  A  frame  axiom  P  is  a  logical  axiom  |-  P. 
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Terms  and  predicates  in  assertions  may  contain  calls  to  LISP  functions.  If  the 
frame  definition  contains  functional  terms  or  predicate  tests  that  are  evaluated  by  ceIIi' 
to  LISP  functions,  the  set  of  premisses  must  be  expanded  to  include  both  the  input- 
output  assertions  for  thj»se  function  calls  and  the  logical  axioms  for  the  relevant  data 
types. 

REMARKS  (i)  The  iterative  schemes  S2  permit  the  definition  of  methods  for  constructing 
loops;  they  are  instances  of: 

WEAK  ITERATION  RULE:  QaL{B}Q\H_ 

Q{WH1LE  L  DO  bh 

where  Q  is  the  invariant  of  the  loop.  The  meaning  of  |-Q  in  the  premiss  is  that  the  rule 
may  only  be  applied  in  states  where  Q  is  a  first  order  consequence  of  the  state 
description.  The  program  part  ??  is  restricted  to  be  a  sequence  of  assignment 
statements  (see  Section  6). 

(ii)  Inconsistencies  may  arise  in  several  different  ways  in  frames.  The  axioms  can  be 
inconsistent,  or  the  post  conditions  of  a  rule  can  be  inconsistent  with  the  axioms.  Also 
the  elements  of  iterative  schemes  must  satisfy  some  simple  consistency  criteria 
(section  6). 

(in)  Note  that  each  frame  rule  has  a  goal.  The  goal  of  a  procedure  is  its  postcondition; 
the  goal  of  an  axiom  or  definition  is  its  consequent. 

The  following  lemma  is  useful  in  proving  properties  of  conditional  assignments 
[Igarashi, London, Luckham  1973]: 


OR-LEMMA 


P{A}Q,  R{A}S 
PvK(m}QvS 


24 


LOGICAL  BASIS  FOR  SEMANTIC  DEFINITIONS 


2.3  A  SIMPLE  kObOTIC  EXAMPLE 

We  will  now  consider  a  simple  robotics  environment  and  its  description  within 
tne  formalism.  In  the  context  of  this  example  we  will  then  consider  formulating  the 
correctness  uf  solutions. 

Consider  the  following  *ramo  and  problem: 

INPUT  FRAME  kULES: 

Fi.  Prucoduro:  stunbon 

MT(x,y//\AT{2,y)Ak0L»0  r(x)AbOX(z){standon(x,2)}ON(x,z). 

K2.  Procedure:  step-up 

KObOT(x)AON{x,y)ASTACi<EUz,y){stcp-up{x,y,z)}ON{x)z). 

K3.  Iterative  Rule:  climb 

kObO  rtM)AON(i4iy)/\S  rACKEUu,y)AONTOP(M){?}ON{M,u) 
kOBOTtM)AON{iv1(y)ASTACKEU{u1y){WHILEONTOP(M)lX)  BEGIN  ?;??  ENDJONTOP(M) 

F4.  Axiom:  kOBOf(x)A3y(ON(x,y)AVz-STACKEiXz,y))«ONTOP(x). 

PROBLEM 

i:  kouOrvM)ALOXvUi)/\LOXtu2}AE.OXvu3)AATtBl,L)AAT(iv1,L) 

ASTACKEUU2,Ui)  a  STACKEU(b3,b2). 

L:  ONTOrfU) 

PROBLEM  1:  CLIMStNG 

REMARKS:  (i)  Tho  iterative  ruie  says  "a  solution  to  the  problem  of  climbing  ono  box  at 
a  timo,  can  be  usoJ  to  construct  a  WHILE  loop  that  solves  tho  problem  of  climbing  a 
stack  of  boxes".  1  he  rule  defines  the  moaning  of  WHILE  in  tho  t  nvironment.  Or  ye 
may  regard  tho  ruie  as  on  induction  principio  for  the  environment. 

fiif  The  program  part  in  the  conclusion  of  the  iterative  rule  transforms  tho  situation 
artor  trie  execution  of  the  loop  body  (?)  back  into  one  in  which  the  invariant  is  again 
true  ir  trie  tost  is  true: 

ON(x,uH??}RObOT(x)AON(x,y)ASTACKED(u,y). 

Wo  restrict  'r t  to  Le  a  sequence  of  assignments. 

fill;  Trie  goei  ot  ciimo  is  UNTOP(M),  the  negation  of  the  control  test  in  this  example. 
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•  t»puj»«t.Y.U} 


|  OKTOf(K) 


search_for  solutions  to  the  climbtnp.  PRORtfm 
Figure  2 


Steps  token  by  o  search  procedure  in  solving  this  problem  are  shown  in  figure 
2.  It  starts  with  stale  situation  I  and  determines  by  logical  reasoning  from  1  and  the 
axioms  Which  operators  have  pre-conditions  that  are  true  in  I  .  „  applies  these 
operators  and  updates  the  state  to  the  new  stale  using  the  rule  of  invariance.  It 
repeats  this  process  on  the  new  states.  Node  6  indicates  the  initiation  o,  a 
subproblem  (the  premiss  of  the  iterative  rule)  with  a  new  initial  state  (the  invariant) 

Which  is  a  subset  of  the  state  above  it  at  Node  5.  The  solutions  corresponding  to  the 
paths  shown  in  figure  2  are: 

(i)  I{standon(M,Bl);stepup(M,Bl,62);stepup{M,B2,63)}0NT0P(M). 

(ii)  I{standon(M,Bl );y«-Bl;u<-B2; 

WHILE  -ONTOP(M)  DO  BEGIN 
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stepup(M,y,u); 

y<-u; 

IF  STACK£D(w,y)THEN  u*-w; 
END)ONTOP(M) 


where  the  assignments  within  the  WHILE  loop  correspond  to  the  ??  of  the  iterative 
rule.  The  variable  w  is  a  special  variable. 


Using  the  frame  rules  we  can  now  construct  a  proof  of  the  statement 
I{solution}ij  within  the  logic  of  programs. 


1.  I3(R0B0T(M)aAT(M,L)aAT(B1,L)aG0X(B1)) 


2.  I{standon(M,Bl)}ON(M,Bl)ASTACKED(B2,Bl)AROBOT(M)  1  ,F1  ,R4,R1  ,R3 

3.  OINKM,B  1  )aSTACKE[XB2,B  1  )AR060T(M){y«-B  1; 

u«-B2}ROGOT(M)AON(M,y)ASTACKED(u,y)  R0(i),R2,R3 


4  I{standon(M,Bl);y«-BliU«-B2}RO60T(M)A0N(M,y)ASTACKED(u,y)  2,3,R2 

5.  ROBOT(M)AON(Mpy)A$TACKED(u,y){stepup(M,y,u)}ON(M,u)AROBOT(M)  F2,R4 

6.  ROBOT(M)AONttv1Iu){y4-u)ROBOT(M)AON(M,y)  R0.R3 

7.  0N(M1y)A3zSTACKED(z,y){IF  STACKtDfw.yJTHEN  u«-w}ON(M,y)ASTACKELKu,y)  R0,R3 

8.  -3zSTACK£D(z,y)AONrOP(M){iF  STACKED(w,y)THEN  u*-w}ONTOP(M)  RO 


9.  (0N(M,y)A32STACKED(z,y))v(^3zSTACK£D(z,y)A0NT0P(M)) 

{IF  STACKED(w,y)THEN  u«-w}(ON(M,y)ASTACKED(u,y))v  ONTOP(M)  OR-Lemma  7,8. 


10.  R0E0T(M)A0N(M1y)A-(3z)STACK£D(zly)  o  ONTOP(M)  FA, 
^(ON(M,y)A3zSTACKED(z,y))vONTOP(M) 

oA^?M)A0N{W,y)A  ^3TMCK£Wz,y)  =  (ON(M,y)A3zSTACKED(z,y))vONTOP(M) 
RObOT(M)AON(M,y)  3  (ON{M,y)AjzSTACKED(z,y))vONTOP(M) 


1 1.  RObOT(M)AON(M,y)A$TACKED(uly){stepup(M,y,u),'y«-u; 

IF  STACKED(w,y)TH£N  u<-w}<ON(M,y)ASTACKED(u,y))v  ONTOP(M)  5,6,10,9,R2,R1 

12.  ROBOHM)AON(M,y)ASTACKED(u,y){WHILE-ONTOP(M)  DO  ...}ONTOP(M)  11,R1,F3 

13.  I{so!ution  (ii)}ONTOP(M)  A,12,R2 


PhOOr  of  Ifsolution  (ii)}G 
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We  refer  to  a  formal  proof  of  L(F)||-I{A}G  as  a  correctness  proof.  The  existence 
of  such  a  proof  implies  only  that  the  program  is  correct  relative  to  the  frame.  If  we 
modify  the  frame  we  can  investigate  the  correctness  of  solution  (ii)  in  the  extended 
frame  by  analyzing  the  proof  of  I{solution  (ii)}0NT0P<M)  by  checking  to  see  if  any  step 
uses  facts  from  an  intermediate  state  situation  I’  that  contradict  the  extra  logical  rules. 
We  in  effect  carry  out  a  "proof  checking"  operation  for  consistency  of  each  step  with 
the  additional  facts.  This  process  practically  avoids  search. 
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3.  DEFINING  THE  PROGRAMMING  ENVIRONMENT 

In  this  section  the  Frame  definition  formalism  is  presented.  This  includes  the 
Frame  language  the  Advice  language,  and  the  output  Program  language.  A  complete 
example  of  an  input  frame,  together  with  advice,  and  the  resulting  output  pregram  is 
given. 

3.1  FRAME  LANGUAGE 

3.1.1  ASSERTIONS:  The  syntax  for  assertions  used  in  definitions  of  rules,  axioms  and 

state  descriptions  is  shown  in  figure  3. 

<variablo>  ::•»  <idontifier> 
function  symbc<>  ::•*  <identifier> 
predicate  symbo  >  <identifier> 

<term>  <variable>|(<funciion  symbol>)| 

(<function  symbol><argument  list>) 

<argument  list>  <term>j<term>,<argument  list> 

<functional  term>  (EV<term>)|(EVN<term>)|<term> 

<atomic  formula>  <predicate  symbol>(<predicate  argument  list>) 

<predicate  argument  list'-  <functional  term>|<functional  term>, 

predicate  argument  list> 

<literal>  ::=  <atomic  formula>|-<atomic  formula> 

literal  element>  <literal>|R£QUEST(<literal>)|f<assertion>} 

<disjunction>  <literal  element>|<literal  elemert><or><disjunction> 

<assertion>  <disjunction>|<disjunction><and><assertion> 

<ar  d>  a|& 

<oi  >  v|® 

SYNTAX  OF  ASSERTIONS 
Figure  3. 

Identifiers  are  strings  of  characters  not  containing  the  negation  symbol,  nor 
the  usual  LISP  delimiters,  e.g.,  blanks,  commas  or  parentheses.  The  <or>  connectives 
have  higher  precedence  than  the  <and>  connectives  and  a  logical  condition  is 
terminated  by  a  semicolon,  For  example, 

P(x)  v  Q(x)  a  R(x,y)  a  S(Z,x)  v  {T(Z>  a  MV)}; 

roprosents  the  expression 

[P(x)  v  Q(V)]  a  R(x,y)  a  [$<Z,x)  v  [T(Z)  a  M(V)]] 


a  ..  . . -  - - - . -  — . — 
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in  fully  parenthesized  notation. 

The  only  constructs  whose  meaning  requires  special  explanation  are  <funchonal 

term>,  literal  element>,  and  the  connectives  and 

If  a  term  is  in  the  scope  of  the  modifier  "EV"  then  all  functions  in  (hat  term  are 
applied  to  their  arguments  (i.e.  evaluated  as  LISP  functions)  when  ‘.hat  literal  is  used  in 
the  problem-solving  process.  "EVN"  further  specifies  that  the  functions  to  be 
evaluated  have  numerical  values.  The  default  convention  is  that  the  form  is 
manipulated  as  an  unevaluated  symbolic  expression.  The  "REQUEST"  modifier,  which 
takes  a  literal  as  its  argument,  alters  the  way  that  literal  is  treated  by  the  problem 
solver.  This  is  discussed  in  Section  4. 

The  AND  connective  is  denoted  by  "a"  .  Thus  a  state  satisfies  the  assertion  AaB 
if  it  satisfies  both  A  and  B.  The  weaker  THAND  connective  is  denoted  by  &.  Exclusive 
OR  is  denoted  by  *»". 

3.1.2  STATE  DESCRIPTIONS:  Assertions  specifying  states  are  restricted  to  be 
conjunctions  of  literals. 

3.1.3  AXIOMS:  Axioms  are  stated  in  either  of  the  forms  P=Q  or  P,  where  P  and  Q  are 
assertions.  They  hold  in  all  states  and  are  used  to  complete  a  given  state  description 
by  deduction  of  other  elements  of  a  state  from  those  given. 

3.1.4  RULES:  There  are  three  types  of  rules:  primitive  procedures,  definitions,  and 
iterative  rules. 

(a)  A  primitive  procedure  is  specified  by  a  name,  an  argument  list,  and  its  pre  and 
post-conditions,  i.e. 

P  {f  (xi  r..,xk  )}Q  where  P  and  Q  are  assertions  in  which  xi  ,..,X|t  are  free,  and 


f  is  the  procedure  name. 
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THe  variables  are  formal  parameters  of  the  procedure.  They  may  be  "bound"  by 

substitution  of  actual  parameters  when  the  procedure  is  applied  to  a  state 

For  example  consider  the  operator, 

move(Rl,01,Ll,L2):"Rl  makes  01  from  LI  to  L2"; 
with  preconditions, 

ROBOT(Rl)  a  MOVABLE(Ol)  a  AT(01,L1)  a  AT(R1,L1)  a-  0N(R1,02,L1); 
and  postconditions, 

AT(01,L2)  A  AT(R1,L2); 

When  a  primitive  procedure  is  defined  it  may  be  declared  to  be  an  ASSUMPTION. 
If  it  is  used  in  a  successful  program  construction,  then  the  user  is  informed  and  is 
given  the  opportunity  to  carry  out  a  structured  program  development  of  this  non¬ 
primitive  operation.  This  is  described  in  Section  7. 

(b)  A  definitional  rule  is  of  the  form  R*S  where  R  and  S  are  assertions.  The  relation,  S, 
is  given  as  the  postcondition  of  the  rule.  The  meaning  of  a  definition  is  that  whenever 
it  is  desired  that  S  be  true  it  is  equivalent  to  establish  the  truth  of  R.  A  definition  is 
often  used  to  shorten  assertions  in  rules  by  defining  a  single  relation  as  equivalent  to 
an  often  used  condition. 

(c)  Iterative  rules  specify  conditions  that  if  satisfied  justify  the  assembly  of  a  "while" 
loop  to  achieve  the  associated  goal.  They  are  instances  of  the  iterative  rule  S2  in 

Section  2.2,  and  are  defined  by  giving: 

(u  A  name,  e.g.  TLOOP,  (without  parameters). 

(ii)  A  basis  assertion  P. 

(in)  A  loop  invariant  assertion  Q  that  specifies  relations  that  must  be  true  in 
the  state  prior  to  each  iteration. 

(iv)  An  iteration  step  assertion  R  that  specifies  the  goals  to  be  achieved 
during  an  execution  of  the  loop  body. 

(v)  An  iterative  goal  G,  the  assertion  considered  achievable  by  the  iterative 
process. 

(vi)  The  format  of  iterative  rules  also  allows  the  specification  of  a  loop 
control  test  L  and  an  output  assertion  $  if  they  differ  from  G. 
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The  rule, 

TLOOP 

P;Q;R;G;L;S; 

where  P,Q,R,G,L  and  S  are  assertions, 
defines  the  iterative  rule  "TLOOP" 
associated  with  the  goal  G. 

3.1.5  SPECIAL  AXIOMS:  After  the  rules  and  initial  state  have  been  oefined  the  system 
requests  the  following  information  for  each  predicate  symbol  P  that  has  been 
mentioned.  The  system  use  of  this  information  is  discussed  in  Section  A. 

a)  Is  P  a  function  of  the  state?"  The  intent  of  this  classification  is  to  separate 
those  relations  whose  truth  value  may  be  affected  by  a  state 
transformation,  i.e.,  FLUENT  relations, from  those  whose  truth  value  is 
constant  over  all  achievable  worlds,  i.e.,  NON-FLUENT  relations  such  as 
"ROBOT(X)",  "INTEGER(Y)". 

b)  Is  knowledge  represented  using  P  partial?"  A  partial  relation  may  have 
truth  values  TRUE,  FALSE,  or  UNDETERMINED.  Partial  relations  may  be  used 
to  represent  incomplete  knowledge  of  the  world  which  may  cause 
conditional  statements  to  be  generated  as  explained  in  Section  5.  A 
relation  may  be  declared  "uncertain"  which  implies  an  absence  of 
knowledge  about  it  so  that  .  is  assigned  a  truth  value  of  undetermined  a 
priori.  If  P  is  not  "partial"  it  is  "total"  and  can  only  have  truth  values  of 
either  true  or  false.  Thus  rule  R6  applies  to  partial  predicates  only. 

c)  Does  P  have  a  uniqueness  property  in  certain  argument  positions?"  A 
"yes"  answer  indicates  that  P  cannot  be  true  for  two  sequences  of 
argument  values  that  differ  only  at  one  of  those  positions  that  are  unique. 
The  unique  positions  are  given  using  the  notation,  (Xl,*,X3,V->Xn),  for 
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example,  to  designate  the  second  and  fourth  argument  positions.  For  each 
umque  argument  position  in  relation  P(alr..,an),  an  axiom  is  "built-in"  from 

which  a  contradiction  may  be  established  with  P(bl . bn)  that  differs  in  a 

unique  position  and  matches  elsewhere. 

The  statement,  "an  object  can  only  be  in  one  place  at  one  time",  is  expressed  by, 
AT(X  1  ,*),  If  we  add,  "and  only  one  object  can  be  at  any  place",  then  we 

use  AT(*,*). 

3.1.6  SIMPLIFICATION:  Algebraic  simplification  roles  may  be  given  to  simplify  the  terms 
that  may  occur  in  sobgoals  during  the  problem  solving  phase.  The  simplification  is 
driven  by  a  table  of  rules  of  the  form  s-t  where  s  and  t  are  terms:  occurrences  of  s* 
are  replaced  by  to c  for  any  substitution  oc. 

The  output  format  of  any  functional  term  may  be  specified  by  the  user  by  giving 
a  rule  in  which  its  input  prefix  form  is  on  the  left,  e.g.,  (PLUS  X  Y)  .  (X+Y). 
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COMMAND  SYNTAX 

ACTION  PERFORMED 

TRY  <rulel>  BEFORE  <rule2> 

Use  <rulel>  before  <rule2>  to 
develop  a  subgoal. 

FOR  <rule>  [FIRST]  TRY  <literal> 

Change  the  precondition  Q  of  <rule> 
to  <li tera 1>  &  Q  if  "FIRST"  is 

given  otherwise  Q  v  <literul>. 

DELETE  {<rule>,<literal>, 

<advice  num>) 

If  <rule>  is  given,  remove  that 
rule.  If  <literal>  then  altei 
state  to  make  <literal>  not  true. 

If  <advice  num>  then  delete  the 
associated  advice  and  undo  its 
effects  on  the  system. 

ADD(<rule>,<literal>J 

If  <ru le>  is  given  then  accept  a 
new  rule.  If  <Cliteral>  then  alter 
state  to  make  <literal>  true. 

ALTER  <rule> 

<rule>  may  be  modified. 

ASSUME  {<rule>,<literal>} 

If  ^rule>  is  given  then  an  assumed 
rule  may  be  defined. 

If  <iiteral>  then  alter  state  to 
make  <literal>  true  and  mark  it  as 
an  assumption. 

RESTRICT  <rule>{ TO , FROM] 

<rule  list> 

For  any  goal  in  Q,  if  "to"  is  given 
then  only  rules  in  <rule  list>may 
be  used,  if  "FROM"  then  no  rule  in 
<rule  list>  will  be  used. 

ADVICE 

All  advice  given  that  session  is 
displayed . 

STATUS 

The  following  information  is  dis¬ 
played  : 

-rules  entered  and  goals 
pending  in  current  subgoal 
tree  , 

-rules  and  goals  in  longest 
path  obtained  so  far, 

-currently  constructed  program 
segment 

-longest  program  segment 
constructed  so  far. 

PAIRWISE  INEQUALITIES  <proc> 

Pairwise  equality  is  prohibited 
in  primitive  procedure  argument 
positions  containing  "*". 

RECURSIVE  <rule> 

The  rule  may  be  used  directly  to 
achieve  a  goal  in  its  pre-condition, 
otherwise  it  may  not. 

Figure  4 


-M>.  --W. 
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3.2.  ADVICE  LANGUAGE 

The  advice  facility  is  intended  to  enable  the  user  to  impose  structure  relevant  to 

solving  a  parhcular  problem  upon  an  already  defined  frame.  This  additional  structure 

includes  preference  orderings  among  goals  and  rules,  and  reslrictons  on  the  search 

space.  The  preferences  may  also  reflect  the  kind  of  solution  the  user  wants. 

Advice  is  given  during  program  generation  by  means  of  an  interactive  facility. 

The  advice  subsystem  may  be  entered  by  responding  to  a  system  query,  "00  YOU 

HAVE  ADVICE?  ,  or  by  typing  any  key  during  program  generation.  The  user  may 

request  to  see  the  current  path  in  the  subgoal  tree  i.e.  rules  entered  and  goals 

pending,  and  receive  a  diagnosis  of  the  cause  of  any  failure.  This  is  useful  in  deciding 
what  advice  to  give. 

The  advice  system  enters  a  read  loop  recognizing  and  numbering  commands  from 
guage  shown  in  figure  A.  In  the  language  syntax,  opiional  symbols  are  enclosed 
In  T  and  "]";  enclosing  a  list  of  symbols  in  T  and  ")"  indicates  that  one  must  be 
chosen;  <rule>  is  a  rule  name;  <rule  list>  is  a  list  of  rule  names;  <proc>  is  a  primitive 

procedure  name;  <advice  num>  is  of  the  form  "an",  where  n  is  an  integer;  and  Q 
denotes  the  pre-condition  of  <rule>. 

After  advice  has  been  given  the  system  may  be  directed  to  re;ect  the  rule  it  is 
currently  using,  if  any,  or  to  try  (perhaps  re-try)  the  current  rule. 

The  advice  facility  is  an  important  tool  for  experimenting  interactively  with 
different  frames  to  determine  their  adequacy  and  soundness.  At  present,  the  language 
IS  rudimentary  and  should  be  extended. 

3.3  PROGRAMMING  LANGUAGE 

The  generated  programs  are  expressed  in  an  elementary  ALGOL-like  language 
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which  includes  block  structure,  assignment  statements,  conditional  statements,  while 
loops,  and  non-recursive  procedures  calls.  The  procedures  may  be  typed,  including 
Boolean,  and  may  have  side  effects  in  addition  to  the  value  returned.  The  procedure 
parameters  are  normally  called  by  value  except  in  the  case  of  special  W-variables  in 
conditional  assignments  (rule  RO, section  2). 
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3.4  AN  EXAMPLE 

Consider  the  task  of  writing  a  program  to  compute  the  nth  Fibonacci  number  for 

some  integer  n.  This  task  has  been  posed  in  [Balzer  1972].  The  basic  information 

required  is  the  recursive  definition  and  the  basis  values.  One  way  to  express  this  in 

the  Frame  language  "ses  the  following  predicates  with  the  indicated  meanings: 

VFIB(X,Y):  "The  value  of  the  X  Fibonacci  number  is  Y", 

C(X,Y):  "The  contents  of  the  variable  X  is  Y", 

S5!£>:  "Th®  vanable  x  contains  the  Y  Fibonacci  number, 

INTEGER(X):  "X  is  an  integer", 

ISVAR(X):  "X  is  a  variable", 

>(X,Y):  "X  is  greater  than  Y" 

NEWVAR(X,Y):  "X  and  Y  are  local  variables". 

The  problem  is  ISVAR(X3)aINTEGER(N){?}FIB{X3,N). 

The  frame  contains: 

1.  Axioms  VFIB(l,l).nd  VFIB((ADD1  l),2Xthese  define  initi.l  values). 

2.  Axiom 

TAFIB 

VKID(V1UV4\  V1),V2)AVFIB<(SUB1<SU01  V1)),V3)A  «<V4,(PLUS  V2  V3)); 

(defines  VF1B(V1,V4j  for  terms  beyond  the  initial  values). 

3.  An  iterative  rule  (named  TFIB)  with  goal  FIB(X3,N);  this  rule  defines  the  conditions 

to  be  satisfied  during  an  iterative  upward  computation.  The  basis  condition  (to  initialize 
the  counter  and  program  variables)  is: 

NEWVAR(  VI  ,V2)aINTEGER(  V8)aC(  V 1  ,(ADD  1  1))aC(V2,1)aC(V3,(ADD1  1))^ 

The  loop  invariant  condition  is: 


This  states  that  at  each  entry  to  the  loop  body,  if  the  value  in  the  counter  is  i  and  the 

values  in  the  program  variables  are  j  and  k  then  j  is  the  ith  Fibonacci  number  and  k  Is 
the  (i-l)st  Fibonacci  number. 
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The  iteration  step  condition 

C<V1,{ADD1  V5))aFIB(V2,V5)aFIB(V3,(ADD1  V5))j 

specifies  what  the  iteration  step  is  to  accomplish.  The  control  test,  >(V5,V8)  and  an 

Output  assertion  FIB(V3,V8)  are  given. 

4.  A  definition  of  FIB  in  terms  of  VFIB  and  C 

TDFIB 

VFIB(V2,V3)aC(V4,V3);  FIB(V4,V2); 

5.  A  simple  primitive  procedure  for  assignment  is  also  given,  i.e. 

«-(Vl,Al) 

ISVAR(Vl);  C(Vl,Al)j. 

No  rules  are  ceclared  as  assumptions.  The  additional  information  given  to  complete  the 
frame  specification  is  shown  in  figure  5,  and  a  program  generated  from  this  frame  is 
shown  in  figure  6. 
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predicate  symbol 


FLUENT 


c 

FIB 

> 

VFIB 

INTEGER 

■ 

ISVAR 


TRUE 

TRUE 

TRUE 

TRUE 

FALSE 

TRUE 

FALSE 


PARTIAL 


UNIQUENESS 


FALSE 

FALSE 

FALSE 

FALSE 

FALSE 

FALSE 

FALSE 


C(X.«) 

FIB(X,  •) 

FALSE 

VP  I B  ( * ,  * ) 

FALSE 

FALSE 

FAI.SE 


SIMPLIFICATION  RULES 


FUNCTION  OUTPUT  SYNTAX: 


(ADD!  (SUB1  X))  .  X 

(SUB1  (ADD1  X))  X 


(ADDI  X)  -  (X+l) 
iSUBl  X)  -  (X-I ) 
(PLUS  X  Y)  -  (X+Y) 


ADVICE:  TRY  TFIB  BEFORE  TDF1B 
RECURSIVE  TAFIB 


Figure  5 


»  #(H»  •  »»*» 


PROCl  (X3,N) 

ISVAR( X3) I INTECER(N) ; 
COMMENT 

INPUT  ASSERTION 
NONE 

OUTPUT  ASSERTION 
FIB(Xj5,N) 

BEGIN 

VI  -  (l+l); 

Y2  -  1; 

X3  -  (l+l); 

WHILE  — i>(Yl  ,N)  DO 
bEGIN 

Y1  -  (Y1  +  1); 
Z2  -  X3 ; 

X3  -  (XJ  +  Y2 ) ; 
Y2  -  Z2 ; 

END 

END 


Figure  6 
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4.  PROBLEM  SOLVING  PROCESSES 

During  the  process  of  problem  solving  and  program  generation,  information  is 
needed  at  many  points  to  reduce  the  search  space  or  to  produce  reasonable  programs. 
Some  of  the  information  is  provided  in  the  frame  specification  by  statements  about  the 
rules  and  predicates;  other  useful  facts  are  provided  to  the  problem  solver  in  the  form 
of  rather  simple  advice.  Roughly  speaking,  there  are  six  basic  processes  in  the 
problem-solving  system  where  extra  facts  can  help:  (a)  pattern  matching,  (b) 
development  of  nodes  in  the  subgoal  tree,  (c)  updating  the  state  description  (i.e. 
implementing  invariance),  (d)  backtracking  in  the  subgoal  tree,  (e)  conditional  branching, 
(f)  assembly  of  programs.  Each  fact  (as  opposed  to  a  rule  or  axiom)  in  a  frame 
specification  and  each  sort  of  advice  has  at  least  one  function  in  speeding  up  a  basic 
process.  Below  we  describe  some  of  the  ways  in  which  the  present  variety  of  facts 
and  advice  is  used. 

(1)  OR-Node  Selection.  When  more  than  one  rule  can  be  applied  to  reduce  a  given 
goal,  some  selection  and  preference  criteria  are  needed.  By  using  the  advice 
system, the  rules  and  axioms  that  may  be  applied  to  achieve  goals  within  the 
precondition  of  a  rule  or  axiom  may  be  restricted  to  or  excluded  from  a  given  list. 
Also,  a  preference  ordering  may  be  specified  among  rules  and  axioms  with  common 
post-conditions.  Goals  within  the  preconditions  of  axioms  are  always  restricted  to 
deduction  within  the  current  state,  i.e.  can  be  reduced  only  by  use  of  other  axioms, 
and  do  not  cause  a  state  transformation  nor  add  any  construct  to  the  generated 
program. 

(2)  Predicate  Classification.  A  predicate  P  is  classified  according  to  the  kind  of 
subgoaling  permitted  to  achieve  a  goal  of  the  form  P(t).  If  P  is  declared  to  be  NON- 
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FLUENT,  then  any  goal  literal  containing  P  can  be  achieved  only  by  deduction  from  the 
current  state.  No  rules  (procedure,  iterative  or  definitional)  are  applied.  FLUENT  goals 
are  attempted  by  deduction  and  state  transformation.  If  a  fluent  predicate  occurs  in  a 

literal  which  is  the  argument  of  the  REQUEST  modifier,  then  it  is  treated  as  a  non¬ 
fluent. 

(3)  Goal  Ordering.  The  achievement  of  a  condition  (and  the  efficiency  of  the  output 
program)  is  strongly  influenced  by  the  ordering  of  its  subgoals.  In  particular,  the 
bindings  of  variables  occurring  in  goals  may  be  determined  by  earlier  achieved 
instances.  In  some  cases  only  certain  orderings  will  permit  achievement.  An  objective 
of  an  automatic  problem  solving  system  is  to  determine  the  optimal  subgoal  ordering, 
but  at  present  this  is  provided  by  the  user  when  the  Frame  is  defined  and  may  be 
altered  by  advice.  However,  the  system  automatically  orders  non-fluent  goals  first  in  a 
condition;  this  relatively  short  achievement  search  is  used  both  as  a  quick  rejection 

strategy  and  to  get  variable  bindings  of  the  correct  type  for  the  remaining  fluent 
goals. 

(4)  Recurring  failures.  When  failure  occurs  in  some  subtree  prior  to  successfully 
solving  a  subproblem,  its  causes  should  be  used  to  avoid  repeating  the  same  failure  in 
the  continued  search  if  possible.  At  present  this  must  be  handed  using  the  interactive 
advice  system.  This  informs  the  user  of  the  current  path  in  the  subgoal  tree,  current 
program  generated,  and  goals  that  fail,  thus  allowing  interactive  correction  when  a 
repetition  occurs.  These  situations  can  also  be  eliminated  by  placing  the  (eventual) 
successful  subprograms  on  the  program  library  for  use  as  MACROS. 

(5)  Repetition.  Certain  types  of  looping  behavior  in  the  subgoaler  are  prevented  using 
the  feature  of  the  Frame  language  that  allows  a  rule  to  be  declared  recursive  or  non- 
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recursive.  If  declared  non-recursive,  then  that  rule  will  not  be  used  directly  to 
achieve  a  goal  in  its  pre-  condition  and  it  will  not  be  entered  twice  to  achieve  the 
same  instance  of  its  post-condition  within  the  same  subgoal  tree.  A  more  general 
mechanism  should  consider  not  only  the  current  goal  and  rule  but  also  the  current 
state  as  well. 

(6)  Truth  Values.  Though  the  underlying  semantics  is  three  valued,  search  efficiency  is 
gained  by  restricting  relations  involving  certain  predicate  symbols  to  be  two  valued.  If 
a  predicate  P  is  declared  to  be  TOTAL,  then  failure  tc  achieve  P  indicates  that  ->P  is 
true.  Only  true  positive  instances  of  total  predicates  are  stored  in  the  state.  The  rule 
of  undetermined  values  is  not  applicable  to  literals  involving  total  predicates.  The 
additional  processing  required  for  PARTIAL  predicates  is  described  in  Section  5. 

(7)  Useless  Procedure  Calls.  In  some  cases,  the  application  and  generation  of 
redundant  or  trivial  procedure  calls  are  detected  and  avoided.  At  the  moment  this  is 
done  by  placing  restrictions  in  the  frame  on  the  actual  parameters  of  primitive 
procedures.  The  system  will  not  use  an  instance  of  a  primitive  procedure  that  contains 
pairwise  equality  between  its  actual  parameters  that  has  been  prohibited  by  the  user. 
For  example,  the  advice  "PAIRWISE  EQUALITY  M0VE(xl,x2,*,*)"  will  cause  the  Rejection 
of  the  procedure  call  "M0VE(MAN, CHAIR, P,P)r'. 

(8)  Uniqueness  Properties.  Uniqueness  or  single-valuedness  in  argument  positions  of 
certain  predicates  is  sufficiently  important  to  justify  a  special  mechanism  rather  than 
to  rely  on  deduction  using  axioms.  The  designation  of  certain  argument  positions  as 
unique  is  equivalent  to  efficiently  building  in  axioms  of  a  particular  form,  e.g.  P(xl,$) 
represents  the  axiom, 

P(xl,x2)  a  x2  ft  x3  ->  -«P{xl,x3). 

These  special  axioms  are  used  for  consistency  checking  (in  the  implementation  of  the 
rule  of  invariance)  when  the  state  is  updated. 
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(9)  Context  Linking.  The  context,  which  includes  the  state  and  bindings  on  subgoals 
currently  pending  at  a  node,  should  be  available  to  aid  search  decisions,  e.g. 
instantiations  of  subgoals  or  choice  of  rule,  at  descendent  nodes  in  the  subgoal  tree. 
The  system  has  a  mechanism  that  if  requested  will  keep  track  of  the  instantiated  goals 
at  each  level  of  the  subgoal  tree  so  that  their  variable  bindings  are  available  when 
attempting  lower  level  goals  that  precode  them  in  the  depth  first  ordering.  This  is 
used  to  instantiate  the  lower  level  goals.  For  example,  suppose  Q(b)  a  P(a)  is  a 
condition  to  be  achieved  and  a  primitive  procedure  R(y)  A  P(x)  {p(x,y)}Q(y)  is  applied 
to  achieve  0(b),  then  for  the  P(x)  in  the  precondition  of  p,  P(a)  will  be  used  since  it 
must  be  achieved  at  the  higher  level  anyway,  i.e., 

/  \ 

/  \ 

0(b)  P(a) 

A 

/  \ 

R(b)  P(x)  (<x*-a>) 

This  heuristic  may  be  viewed  as  the  opposite  of  subsumption,  the  strategy  being  to 
get  ground  instances  as  soon  as  possible  to  help  avoid  long  searches  using  rules.  This 
is  a  rather  restrictive  strategy  that  may  exclude  solutions  and  is  only  used  when 
requested  by  the  user. 

(10)  Evaluation  of  Predicates  and  Functions.  For  certain  predicates  occurring  in 
subgoals,  achievement  is  most  efficient  by  direct  evaluation.  If  a  literal  occurring  in  a 
goal  is  formed  with  a  predicate  that  has  a  LISP  definition,  then  that  literal  is  evaluated 
as  a  LISP  statement.  Special  processes  or  even  subsystems  can  thereby  be  linked  into 
program  generation.  Evaluation  of  arbitrary  functions  occurring  in  terms  in  arguments 
of  goal  literals  is  done  if  the  function  occurs  in  the  scope  of  an  EV  modifier.  These 
evaluations  assume  the  soundness  of  implicit  axioms  describing  the  LISP  definitions, 
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and  the  consistency  of  these  axioms  with  the  Frame.  For  example,  the  equality 
predicate,  is  evaluated  using  the  LISP  "EQUAL",  and  the  predicate 

NEWVAR(xl,x2....,xn)  takes  an  arbitrary  number  of  arguments  and  binds  each  Frame 
variable  xi  to  a  new  program  variable  (for  use  perhaps  as  a  local  variable  in  a  block). 

(11)  Simplification  rules.  Rules  of  the  form  s  -+  t  where  s  and  t  are  terms,  may  be 
included  in  the  Frame.  Such  rules  are  applied  to  simplify  terms  in  goals  by  replacing 
occurrences  of  soC  by  toC.  This  not  only  reduces  the  complexity  of  terms  in  the 
subgoal  tree,  but  it  also  modifies  the  pattern  matching  process  and  the  set  of  rules 
that  can  be  applied  to  reduce  a  goal. 

(12)  Computing  Input/Output  Assertions.  In  Section  2  primitive  procedures  were 
viewed  as  Frame  rules  of  the  *jrm  |j-P{p}Q,  where  P  and  Q  are  the  pre  and 
postconditions  for  p.  The  conditions  P  and  Q  may  also  be  v.ewed  as  sufficient  input 
and  output  assertions  for  p  ,  that  must  be  satisfied  by  the  actual  parameters  of  p.  For 
any  generated  program  segment  A,  the  input  assertion  Ia  is  computed  as  the 
conjunction  of  all  literals,  I,  from  a  state  that  were  used  in  achieving  subgoals 
encountered  during  the  generation  of  A  and  did  not  occur  in  that  state  as  a  result  of  a 
postcondition  of  a  procedure  whose  generation  in  A  preceded  the  addition  of  I  to  la. 
The  output  assertion  0a  is  the  conjunction  of  literals  added  to  a  state  during  the 
generation  of  A  that  are  true  in  the  final  state.  The  usefulness  of  computing  sufficient 
input  and  output  assertions  for  a  program  or  segment  thereof  will  become  apparent 
when  we  discuss  program  generalization  and  the  construction  of  conditional 
statements. 

All  of  these  applications  of  facts  and  advice  with  the  exception  of  (12),  are 
intended  to  have  a  direct  effect  on  reducing  the  growth  of  the  subgoal  tree  (process 
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(b)).  In  addition,  tho  pattern  matching  process  (a)  is  extended  by  (11);  (c)  is  aided  by 
the  restriction  of  truth  values  and  the  special  axioms  (6,8);  (e)  is  dependent  on  (6  and 
12);  (f)  is  aided  by  (3,7,11,12).  There  are  other  techniques,  mainly  details  of  the 
implementation,  some  of  them  heuristic,  that  affect  problem  solver,  particularly  the 
backtrack  (d),  the  updating  (c)  and  assembly  of  programs  (f)  (e.g.  the  implementation  uf 
the  a  connective  by  software  interrupts  that  protect  already  achieved  goals,  includes 
certain  assumptions  about  backtracking  when  an  MNO-node  fails). 


5.  GENERATION  OF  CONDITIONAL  STATEMENTS 

Conditional  statements  are  generated  in  situations  where  the  rule  of 
undetermined  values  (R6)  applies  or  when  the  outcome  of  a  primitive  procedure  is 
uncertain.  In  this  section  the  system  methods  for  constructing  conditionals  will  be 
described  and  an  example  given.  The  question  of  extending  the  formal  algorithm  and 
the  correctness  proof  is  considered. 

5.1  UNCERTAIN  PRECONDITIONS 

As  previously  mentioned,  relations  involving  partial  predicates  may  have  truth 
values  of  TRUE,  FALSE,  or  UNDETERMINED,  whereas  all  other  relations  must  be  either 
TRUE  or  FALSE.  Partially  valued  predicates  are  intended  to  express  the  possibility  of 
an  uncertainty  or  lack  of  knowledge  about  a  state  arising  during  the  problem  solving 
and  program  generation  phase  of  the  system.  The  formal  algorithm  for  deciding  when 
an  uncertainty  has  arisen  is  rule  R6.  As  with  invariance,  the  implementation  of  R6  is 
only  an  approximation  to  the  formal  rule.  The  system  may  give  up  too  early,  but  this, 
in  itself,  does  not  lead  to  incorrect  programs,  merely  redundant  ones. 

5.1.1  UNDcTERMINED  VALUES.  During  the  generation  of  a  program,  uncertainty  may 
arise  when  a  precondition  fc  the  application  of  a  rule  is  UNDETERMINED  with  respect 

to  the  current  state.  The  implementation  of  the  rule  R6  is  described  by  the  following 
definitions: 

DEFINITION  A  literal  I  is  UNDETERMINED  in  a  state  S  if  the  following  conditions  hold: 

(i)  pred(l)  is  partial, 

and  (ii)  the  system  halts  without  solving  S{?}l, 
and  (iii)  the  system  cannot  prove  SuFo-’l. 


Condition  (ii)  means  that  I  is  noi  true  in  S  nor  can  S  be  transformed  into  a  state 
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in  *h.ch  I  is  true.  If  condition  (ii)  is  true  and  -I  is  true  in  S  then  I  must  retain  a  truth 
value  of  FALSE  'no  the  precondition  subgoal  I  must  tail.  Failure  to  prove  -I  from  S 
establishes  a  truth  value  of  UNDETERMINED  for  I  with  respect  to  S.  This  definition 
applies  to  fluent  and  nonfluent  literals  but  since  the  truth  value  of  a  ■nonlluenf  cannot 

be  changed  by  a  state  transformation,  for  them,  it  is  sufficient  lo  use  only  the  logical 
axioms  in  deciding  condition  (ii). 

For  the  more  general  case  in  which  the  precondition  may  be  a  disjunction  of 
literals  we  have  the  definition, 

DEFINITION  A  disjunction  of  literals  (I,  is  UNDETERMINFD  in  a  state  S  if  at  least 
one  literal  is  UNDETERMINED  end  no  literal  can  be  achieved  from  S. 
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5.2  CONDITIONAL  STATEMENTS 

When  a  pre-condition  P  is  UNDETERMINED  in  a  state  $,  a  conditional  branch  is 
inserted  in  the  solution  program.  If  P  is  a  single  literal  I,  then  program  generation  may 
continue  either  along  the  path  in  which  I  is  assumed  to  be  TRUE  and  in  which  future 
goals  are  attempted  with  respect  to  state  S  U{l},  or  along  the  path  in  which  -I  is 
assumed  to  be  TRUE  using  state  S  U{-l}.  The  system  convention  has  been  to  generate 
a  call  to  a  yet  ungenerated  procedure  for  the  latter  case.  The  tasks  of  generating 
such  contingency  programs  are  placed  in  a  subproblem  stack  for  later  attention  (see 
Section  5.5).  Program  generation  continues,  by  convention,  along  the  path  using  state 
S  U  {I}.  This  path  is  referred  to  as  the  "trunk"  program  of  the  tree  of  contingency 
programs  generated  while  attempting  to  achieve  the  main  goal.  The  path  selection  at 
present  is  rather  ad  hoc  since  no  assignments  of  probability  are  made  at  the  points  of 

uncertainty.  For  an  undetermined  disjunction  {I  } 

i  i— 1  ' 

if  ’ll  then 


if  -I2  then 


if  "I*  then  pM 
olso  pB.i 


else  px 
else  pa 

where  each  p|  is  a  call  to  a  program  to  achieve  a  selected  goal  G 

from  state  S,  ■=  S  a  {I,  :  i-j+1  &  i<w  }  a  {-I,  :  lsi<j)  }  and  p0  is  the  trunk 
program  segment  which  satisfies  SAlj{pa  }G  and  forms  the  else-statement  in  the  main- 
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clause  of  the  conditional.  Each  member  of  the  set  of  triples  {(pi  ,  Sj  ,G):l£j£m}  is 
placed  in  the  stack  of  contingencies  and  program  generation  continues  for  pe  The 
assumed  literal,  lx*  is  removed  from  the  state  following  the  generation  of  the  ELSE 
clause  in  the  trunk  program  if  it  is  not  in  the  output  assertion. 
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5.3  SELECTION  OF  CONTINGENCY  GOAL 

The  goal  G  to  be  achieved  by  the  contingency  programs  is  selected  from  the  set 
of  goals  in  the  subgoal  tree  that  are  global  to  the  undetermined  precondition.  Let  us 
refer  to  the  set  of  goals  which  are  below  G  in  the  subgoal  tree,  as  the  SCOPE  of  G. 
The  particular  G  chosen  and  its  associated  scope  affect  the  length  of  pe  ,  duplication 
among  contingency  programs,  degree  of  difficulty  in  generating  contingency  programs 
and  validity  of  their  use.  If  the  structure  of  the  trunk  program  is  to  remain  fixed 
during  contingency  program  generation  then  the  choice  of  G  cannot  be  deferred.  The 
block  structure  of  our  program  language  imposes  the  restriction  that  for  any 
conditionals  in  pe,  a  contingency  goal  G’  must  not  have  a  greater  scope  than  G.  ihere 
is  also  the  problem  that  if  G  is  not  fully  instantiated  then  inconsistent  instantiations 
may  occur  in  different  contingency  programs  which  must  validly  rejoin  the  main 
program  following  the  ELSE  clause.  The  present  system  selects  the  least  global  fully 
instantiated  goal  thereby  satisfying  the  block  nesting  constraint  and  minimizing  the 
scope  while  avoiding  the  problem  of  handling  deferred  instantiation.  This  selection 
process  is  always  effective  in  the  present  system  since  the  top  level  goal  is  fully 
instantiated. 

5.4  REJOIN  CONDITIONS 

When  a  contingency  program  is  generated  its  output  state  must  satisfy  certain 
conditions,  hereafter  called  the  rejoin  condition,  for  return  of  control  to  the  trunk 
program  to  be  correct.  Consider  the  case  of  an  undetermined  goal  L  in  state  S  and  a 
contingency  goal  G  in  figure  7  .  Let  A  and  B  be  program  segments  that  satisfy  S  A 
L{A}G  and  S  a  -L{B}G  and  let  C  be  the  rest  of  the  trunk  program. 
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Figure  7 


Let  R  be  the  output  state  of  B  obtained  by  applying  invariance;  thus  Sa-1{B}R 
and  R=>G.  Similarly,  let  SaL{A}P  where  PdG,  and  let  Q  be  the  sufficient  subset  of  P 
required  as  input  to  C  (see  Section  4(12)).  Then,  the  ktJOIN  CONDITION  for  B  is  R^Q. 
B  is  sriid  to  have  BAD  SIDE  EFFECTS  if  in  fact  R=>Q  cannot  be  established. 
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5.5  SUBPROBLEM  STACK 

The  task  of  generating  a  contingency  procedure  is  specified  by  the  quadruple: 

(<procname>  <state>  <goal>  <rejoincond>) 

where, 

<prccname>  is  the  name  of  the  yet  ungenerated  procedure  that  must 
satisfy  <state>{<procname>)<goal>  a  <rejoincond>. 

At  the  point  in  the  planning  when  the  uncertainty  is  encountered,  the  first  three 
elements  of  the  quadruple  are  placed  in  a  stack.  The  rejoin  condition  is  not  known  at 
this  time  since  it  involves  the  input  assertion  for  the  trunk  segment  C  following  the 
point  where  control  returns  from  the  contingency  plan  to  the  trunk  plan.  After  C  is 
generated,  the  rejoin  condition  is  computed  and  stored  as  the  fourth  element  of  the 
quadruple. 

When  planning  has  been  completed  for  a  trunk  procedure,  if  the  subproblem 
stack  is  not  empty  then  contingency  planning  may  be  done  by  removing  a  quadruple 
from  the  stack  and  posing  this  as  a  program  generation  task.  The  state  of  the  system 
is  initialized  to  the  specified  contingency  state  and  the  subgoaling  system  is  given 
<goal>  as  its  main  goal,  if  it  is  successful  in  achieving  a  state  in  which  the  main  goal  is 
true  then  a  test  is  made  to  see  if  the  rejoin  condition  is  true  in  that  state.  If  it  is  then 
the  procedure  declaration  is  adjoined  to  its  trunk  program.  If  the  condition  cannot  be 
proved,  the  system  allows  the  user  two  alternatives:  (i)  Mark  the  call  to  the  program 
as  an  error  exit  in  the  trunk  program,  or  (ii)  "Fit"  the  program  to  the  trunk  program  by 
posing  the  currently  untrue  rejoin  condition  as  a  new  goal,  constructing  a  new  program 
segment  that  achieves  it,  and  appending  this  segment  to  the  end  of  the  contingency 
program. 

This  process  of  generating  a  trunk  procedure  which  may  create  new  contingency 
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tasks  then  generating  contingency  procedures  as  directed  by  the  user  may  continue 
until  all  contingencies  have  been  processed  and  the  stack  is  exhausted. 

5.6  COMPUTATION  OF  INPUT -OUTPUT  ASSERTIONS 

The  computation  of  input-output  assertions  for  programs  not  containing 
conditionals  is  described  in  Section  4(12).  The  uncertainty  as  to  which  path 
computation  will  follow  in  a  program  containing  conditional  statements  completes 
these  assertions.  The  input-output  assertions  in  this  case  must  be  computed 
incrementally  as  each  contingency  program  is  generated. 

In  the  conditional  statement  shown  in  figure  7,  suppose  we  know  the  minimal 
input  and  output  assertions  for  A  and  B,  say  P{A}Q  and  R{B}S.  then  the  input  and 
output  assertions  for  the  conditional  statement  are 

(L  a  P)  v  (-1  a  R){if  L  then  A  else  B}Q  v  S. 

To  reduce  computation,  We  use  the  simpler  sufficient  input  assertion  P  a  R, 
(Note  that  P  a  R  should  be  consistent  since  it  is  a  subconjunct  of  a  previous  state). 
There  doesn’t  appear  to  be  a  simplifying  approximation  for  output  assertions  . 
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5.7  UNCERTAIN  PRIMITIVE  PROCEDURES 

A  primitive  procedure  q  defined  by  P{q}Q  has  an  uncertain  outcome  if  Q  Is  a 
disjunction.  In  the  present  system,  disjunctive  post-conditions  use  the  exclusive  OR 
connective,  ®  .  This  allows  us  to  define  frame  procedures  that  have  an  intended 
result  hut  may  be  unreliable.  It  is  assumed  that  exactly  one  of  the  possible  outcomes 
will  os  irue  in  the  output  state  .  At  the  point  where  an  uncertain  operator  is  applied, 
the  problem  solver  has  no  knowledge  of  what  the  outcome  will  be  and  a  conditional 
statement  must  be  generated.  Let  Q  be  the  disjunction  of  literals  {l,f1al.  The  first 
outcome  lj  is  considered  to  be  the  normal  (goal)  result  of  executing  q.  Following  the 
inclusion  of  q  in  the  program  in  state  S,  a  conditional  statement  of  the  following  form  is 
generated. 

if  ■>  li  then 

if  -  ll  A  >2  A  I3  a...a  ->  ln  then  p2 
else  If  -•  li  A  1 12  a  I3  A  -  I4  A...A  ■«  ln  then  pj 

else  if  -  li  a  -  l2  a...a  ln_i  a  ln  then  pn 
else  p^i 

where  each  Pi  ,  2  S  j  S  n,  is  a  call  to  a  program  to  achieve  lj  from  slate  S|  -  S  U  {l|  } 
U  {-  l|  :  i  r  ;  &  1  S  i  S  n}  and  p^;  is  an  error  exit.  The  contingency  states  will 
correspond  to  the  n  ways  of  assigning  exactly  one  literal  true  and  the  romaining 


literals  false. 
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5.8  AN  EXAMPLE 

Suppose  a  procedure  is  to  be  generated  for  a  man  to  travel  from  San  Francisco 
to  New  York  given  three  modes  of  travel,  i.e.,  flying,  driving,  or  walking  This  is  similar 
to  the  "airport  problem"  discussed  in  [McCarthy  1959].  A  FRAME  for  this  problem 
consists  of  defining  a  primitive  procedure  for  each  mode  of  travel,  an  initial  state,  and 
relation  information  as  shown  in  figure  8.  A  few  of  the  contingency  programs 
generated  are  shown  in  figure  9. 
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REJ^TIONS _ 

DEFINITION 

FLUENT 

PARTIAL 

ROB(X) 

"X  Is  a  robot” 

FALSE 

FALSE 

FALSE 

auto(x) 

"X  Is  an  autoaobLla" 

FALSE 

FALSE 

FALSE 

plane;x) 

"X  is  an  airplane” 

rALSE 

FALSE 

FALSE 

AIRPOST'X) 

"X  la  an  airport" 

FALSE 

FALSE 

FALSE 

AT(X.Y) 

"X  la  at  location  Y" 

TRUE 

FALSE 

AT(X.-) 

WALKABLE  X,Y) 

"A  walkabie  path  exists  between 

X  and  Y" 

TRUE 

TRUE 

FALSE 

CLEAR(X.Y) 

“Tha  sky  is  clear  betwean  X  and  Y" 

TRUE 

TRUE 

FALSE 

DRIVABLE  X,Y) 

"A  drivable  road  exists  between 

X  and  Y" 

TRUE 

TRUE 

FALSE 

HAS  UMBRELLA  (X) 

"X  has  an  umbra 1 la" 

TRUE 

TRUE 

FALSE 

CRASHED  X.Y.Z) 

"X  crashed  between  Y  and  Z" 

TRUE 

FALSE 

FALSE 

KILLED ,X) 

"X  has  been  killed" 

TRUE 

FALSE 

FALSE 

RUNS( X) 

"X  will  run  properly" 

TRUE 

TRUE 

FALSE 

FLIES' X) 

”X  will  fly  properly” 

TRUE 

TRUE 

FALSE 

raiHITIVE  PROCEDURE _ PRE -CON'D  IT  IONS _ POST-CONDITIONS 


walk(Rl ,L1 ,12 ) 

"R1  walks  Iron  LI  to  12" 

rob:ri)a-.killed(ri)aat(ri,h) 

ACLEAR ( Ll ,  12  )VHASUMBR£  LLA  ,  R I ) 
AWALKABLE(Ll,I2)i 

at;ri,l?) 

drlve(Rl.Cl,Ll,l2) 

"R1  drives  Cl  iron  LI  to  12" 

ROBtRl)A-i  KILLED(R1)AAUT0(C1) 
AT(ClfLl)ARUNS!Cl) 

ADR  I VA  BLE I L 1 , 12  ) AAT  ( R 1 ,  Ll )  ; 

AT(R1 ,12  ) 

AAT(C1,12) 

fly(Rl,Al,Ll.I2) 

”R1  files  A1  fr<B  LI  to  12" 

rob;ri)a-,  k  i  lled  (ri  )a  plane  {  ai  ) 

AAIRP0RT(I2  )AAT (A  I  ,  Ll ) 
AFLIES(Al)ACLEARiLl,12) 

AAT(Rl,Ll)s 

[AT(R1,12)A 

AT(A1,I2)) 

CRASHED’AL  ,  Ll  ,12  ) 
AKILLED(Rl)] 

••••***••••**•*••••**##• •••••••••••• 

INITIAL  STATE 

NOB  NAN)AAUTO(B*OAPLANE  Fill  )AAIRPORT  ,SFO)AAIRPORT' NYC )AAT  MAN, HOME  )AAT(Bfff  , OARAGE  )AAT  (Fill  ,SFO); 

•*  **•••****•****<►••****•#*#••*####«« 

ADVICE 

PAIRWISE  INEQUALITIES:  walk(Rl ,«,•) .drive (R1 ,C1 ,*,*), fly(Rl ,A1 , »,») 

TRY  PLY  BEFORE  DRIVE,  TRY  DRIVE  BEFORE  yALK 


Figure  8 
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; tiane  1 1 1 1  ;a irih>ki  nyc 


TROC  1  MAN  WC) 

HOB  MAN  ;AlTl>  liM. 

COMMFNT 
IN  PIT  ASSERTION : 

AT  MAN  HOME  'CHAR  nuME  lAKACE  .'AT  DMT  (ARAM  AT  I  Ml  SIO 
AT  LIES  (111  'CLEAR  SI  O  NYC  '  Rt  NS  hlW 
MIR1VAKI.L  (A RACE  SlU  'WAITABLE  llo Ml.  GARAGE 
0  IT  TIT  ASSERllo;.: 

AT  BM.  SI  0  'AT  Fill  AC  'AT  ."AN  NYC  ; 

COMMENT 

TROC11  ATI LMTTS_1  o  ALII  1  EVE_  AT  MAN  NTT 
TROC1  ATTT,v!TrS_10  ACHIEVE  AT  HAN  I A  RACE 
TROC  ATTEM1TSJO  ACHIEVE  "  AT  MAN  IARACL 
TROC  ATILMKI  S_TO_ACU  I  EVE  AT  MAS  IARACL 
PROC  ATTEMTISJO  A(HILVE~  AT  MAN  SIO 
TROC.  ATTEMTTS_IO_ALHlEAT:~  AT  MAN  SIO 
TROC'  ATTEMPTS  !C  AUIJKYE  AT  MAN  .NYC 
TROC  A1IEMTTS  TO~ACH1EVe“  AT  HA  .  NYC 
BEGIN 

IE  if  LIES  1  111  THEN 
TROC  MAN  NYC 
ELSE 
BEGIN 

IT  “CLEAR  SIO  NYC!  THEN 
TROC  j  MAN  NYC 
ELSE 
BEGIN 

If  IRONS  BMV  THEN 
TROC-  MAN  SIO, 

ELSE 

BEGIN 

If  -DR1VABLE  CARACE  SFO  THEN 
TROCA  CAN  SfO 
ELSE 

BEC1N 

IF  “CLFAR'HOME  GARAGE,  THEN 
IF  -NIASL'MBKELIA  MAN  THEN 
TROO  MAN  GARAGE) 

ELSE  TROC"  MAN  GARAGE 
ELSE 
BECIN 

IF-iWALKABLE  HOME  CARACE)  THEN 
TROC  IE  MAN  CARAGE  , 

ELSE 

LECIN 

WALK  MAN  HOME  GARAGE 
END 

END 

DRIVE  MAN  BMJ  CARACE  SFO, 

END 

END 

ELY  MAN  MU  SEO  NYC 
IE  iAT(MAN  NYC)  TILN 

IF  —AT (MAN  NYC)  A  CRASHED  (Fill  SFO  NYC) 

PROC1 1 (MAN  NYC) 

ELSE  TRIH'LR(MAN  NYC) 

END 


END 


E  Nl) 


TROC? (MAN  NYC) 

ROflfMAN)  ;AUTO  BMW  ; 

COMMENT 

1NPUT_ASSERTI0N. 

AT  MAN  HOME  'CLEAR  HOME  GARAGE  AAT  BtV  CARACE  )aRUNS  BfW 
ADR1VABLE  CARACE  NYC  aWAI.KABLE  HOME  CARACE, 


Figure  9 
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OUTPUT_ASSERTION: 

AT'hNW  NYClAAT  MAN  LYC)  ; 
COMMENT 


PROC1'  ATTEMPTS_TO  ACHIEVE 
PROCI5  ATTEMPTS_To”ACIIIEVE 
PROCU  AT  TEMPTS_To”aCHIEVE 
PKOC13  ATTEMPTS  TO  ACHIEVE 
PROC  IP  ATTEMPTS”to”acH  IEVe" 
BECIN 


(at 

MAN 

GARACE) 

(AT 

MAN 

(ARACE) 

(AT 

MAN 

CARACE) 

(AT 

MAN 

NYC) 

(AT 

MAN 

NYC); 

IF  — iRUNS(BMJ)  THEN 
PROC1? (MAN  NYC) 
ELSE 

BECIN 


IF  — 1DRIVA8LE  GARAGE  NYC)  THEN 
PROC13(MAN  IYC) 

ELSE 

BECIN 

IF -1  CLEAR  (HOME  CARACE)  THEN 
IF  1  HAS  CM  3RE1.  LA  FUN)  THEN 
PROC14  MAN  GARAGE) 

ELSE  PROC) 5 (MAN  GARACE) 

ELSE 

BECIN 

IF  — 1WALKA8  £  (HOME  GARACE)  THEN 
PROC16  (MAN  GARACE) 

ELSE 

BECIN 

WAUCMAN  HOME  GARACE); 

END 

END 

DRIVE  (MAN  b>U  CARACE  NYC) 

E-wit  ' 


PROC4  MAN  SFO 
ROB  M\N); 

COMMENT 

INPUT  ASSERUON: 

AT (MA?I  HOME  )ACLFAR 'HOME  SF0)AWALKABLE  HOME  SFO) 
OUTPUT  ASSERTION:  *  ' 

AT  :  H\N“SFO) ; 

COMMENT 

PROC  5  ATTEMPTS  T0_ACH1EVE_  (AT  MAN  SFO) 

PROC’U  ATTEMPTS_TO_ACHIEVE  AT  MAN  SFO) 

PROC ATTEMPTS  TO  ACHIEVE”  (AT  MAN  SFO); 

BECIN 

IF  -iCLEAR(HOME  SFO)  THEN 
IF  — iHASUMBRELIA(MAN)  THEN 
FROG. 3 (MAN  SFO) 

ELSE  PROC  4  (MAN  SFO) 

ELSE 

bECIN 

IF-iWALKABLE  HOME  SFO)  THEN 
PROC  3 (MAN  SFO) 

ELSE 

BEGIN 

WALK(M\N  HOME  SFO) 

END 

END 

END 

PROCIJiMAN  NYC) 

RO  B  MA  N ) ; 

COMMENT 

INPUT  _ASSERTION: 

ATAMAN  HOME  JaCLEAR  ;  HOME  NYC)AWALKABLE(HOME  NYC) 


Figure  9  -  continued 
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OtTTPUT_ASSERI  ION: 

AT  MAN'~NYC  ; 

COMM.  ,vr 

PROC,V  ATTEMITSTO  ACHIEVE  AT  MAN  NYC) 
TKOC  ATI EMITS_TO  ACHIEVE^  AT  MAN  NYC 
PROC  ATTEMPTS  T0~ACH1EVK  AT  MAN  NYCL 
BECIN 

IF  -lCLEAK  HOME  NYC)  THEN 
IK  — iHASLMBKELLA  MAN)  THEN 
PROC  .MAN  NYC) 

ELSE  PROC  'MAN  NYC 
ELSE 
BE(,IN 

IE  ■'WALKABLE  HOME  NYC)  THEN 
PROC*0 , MAN  NYC) 

ELSE 

BECIN 

WALK  MAN  HOME  NYC) 

END 

END 

END 


Figure  9  -  continued 


GENERATION  OF  CONDITIONAL  STATEMENTS 


59 


5.9  CORRECTNESS 

Conditional  statements  will  be  correctly  generated  if  the  system  methods  are  an 
accurate  implementation  of  the  conditional  rule,  R5,  presented  in  Section  2.  Referring 
to  figure  7  in  Section  5.4,  if  we  let  S  be  the  output  state  of  C  then  by  construction  and 
by  verifying  the  rejoin  conditions  we  have, 

(1)  I  a  L{A}G  A  Q, 

(2)  Ia-L{B}GaR, 

(3)  Q{C}S, 

(4)  |-  R  o  Q,  (rejoin  condition  verification) 

and  the  correctness  argument  may  then  be  completed  as  follows, 

(5)  I  a  ->L{B}G  a  Q,  (2, 4, Consequence  Rule) 

(6)  I{if  L  then  A  else  B}G  A  Q,  (1,5, Conditional  Rule) 

(7)  I{if  L  then  A  else  B;C}S,  (3, 6, Composition  Rule). 

It  should  be  noted  that  if  conditional  statements  occur  in  B  then  R  may  only  be 
an  approximation  of  the  true  output  state  resulting  from  executing  B  as  discussed  in 
Section  5.6.  Similarly  Q  may  be  only  an  approximation  of  the  true  input  assertion  for 
the  remainder  of  the  program.  In  these  cases  an  incorrect  prograjn  may  result. 
However  the  above  argument  serves  as  a  justification  for  the  system  methods. 


6.  GENERATION  OF  ITERATIVE  STATEMENTS 

An  iterative  rule  allows  the  program  generator  to  construct  a  WHILE  loop 
provided  it  can  construct  a  loop  body  to  satisfy  the  premisses  of  the  rule.  Ultimately 
such  rules  should  require  the  user  merely  to  specify  an  invariant  in  order  to  have  the 
system  write  a  correct  iterative  program.  At  the  moment,  the  user  needs  to  furnish 
some  additional  relevant  facts.  The  algorithms  used  in  the  system  to  implement 
iterative  rules  of  the  form  32  (Section  2)  and  to  assemble  while  loops  are  described 
briefly  and  an  example  given.  Details  of  of  the  system  implementation  are  found  in 
Section  9. 

6.1  PREMISSES  FOR  CONSTRUCTING  A  LOOP 

An  iterative  rule  is  defined  by  the  assertions  P(basis),  Qdoop  invariant), 
Reiteration  step  goal),  G(rule  goal),  L(control  test)  and  S(outpui  assertion).  All  the  free 
variables  in  R  and  L  musi  be  among  the  free  variables  in  Q.  In  order  to  use  the  r.ile, 
to  achieve  I(?]G  say,  the  formal  algorithm  requires  that  a. I  of  the  following  subgoals  be 

achieved  or  be  true: 

(i)  Construct  A  such  that  L(F)||-  I{A}P 

(ii)  L(F)|-  I{A)Q 

(in)  Construct  B  such  that  L(F)||-QaL{B}R 

(iv)  L(F)  |-  QaL{B}(3Z)Q(Z)v(-’(3Z)Q(Z)a--L(Y)) 

(v)  Construct  C  such  that  L(F)  ||-  QaL{B;C}Qv-L 

Note  thnt  (ii)  and  (iv)  are  restricted  to  first  order  rules  (consequence,  invariance,  and 
the  frame  axioms).  The  input  state  for  (iii)  is  O^L-  In  addition,  an  iterative  rule  must 
satisfy  the  following  minimal  consistency  requirements  within  the  frame  F. 

(vi)  MS  u  F  o  L)  and  S  u  F  =  G. 

The  conclusion  of  the  rule  is:  I{A;WHILE  L  DO  BEGIN  B;C  ENDJG. 

Iterative  frame  rules  are  instances  o?  the  iteration  rule  [Hoare  1969]: 

QaL{A}Q,  OaM-oG 


- 
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Q{WHILE  L  DO  A}G  . 

It  is  possible  to  derive  a  weak  form  of  the  rule: 

QaL{A}Qv-L,  ->L3G 
Q{VVHILE  L  DO  A}G  . 

The  weak  form  allows  the  invariant  to  fail  on  exit  from  the  loop.  We  have  found 

the  weak  form  convenient  to  use  in  many  examples. 

The  present  implementation  sets  up  clauses  (i)  -  (iv)  as  a  THAND  of  subgoals  to 
be  achieved.  More  specifically,  suppose  an  iterative  rule  is  invoked  to  solve  the 
problem  I{?}G.  Let  V  be  the  list  of  variables  in  Q.  The  system  does  the  following: 

(1)  A  program  segment  p(P)  is  generated  such  that  I{p(P)}I’  and  PJF  |-  P  (  p(P) 

may  be  empty). 

(2)  An  instance  Q\  of  the  loop  invariant  must  be  true  in  the  state  P,  i.e.  X  -  {<vi 

si  >,.,<vn  -  sn  >}  is  constructed  such  that  I*uF  =>  QX.  (3)  A  program  segment 

p(R)  is  generated  such  that  Q  a  L{p(R)}l"  and  I  uF  o  R. 

(4)  It  is  checked  that  PuF^O/Jv-l  for  some  substitution  fi  and  a  set  of 
conditional  assignment  statements  C  is  constructed  such  that  P{C}Q  v  -L. 

Thus,  at  the  moment,  clause  (iv)  ensures  that  C  need  contain  only  conditional 
assignments.  In  the  future  we  would  want  to  relax  this  restriction.  It  is  assumed  that 

the  user’s  definition  of  the  rule  satisfies  (vi).  The  user  may  omit  S  or  L;  in  the  latter 

case  -  G  is  used  as  the  control  test. 
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6.2  ASSEM8LY  OF  WHILE  LOOPS 

After  the  premisses  have  been  achieved,  a  loop  is  assembled  as  follows: 

(1)  Let  Y  and  W  be  two  distinct  lists  of  variables  in  orie-to-one  correspondence 

witn  V.  For  eacn  <v(  *-  s(  >  <  a,  construct  an  initial  assignment  statement  "yi 

S|  Let  "Y  ♦-  SH  denote  Myi  -  sA  ;  y2  «-  s2  y„  «-  sn 

(2)  The  WHILE  loop  may  then  be  assembled  in  the  form: 

Pi*3); 

Y  -  S; 

WHILE  L(Y)  DO 
LEGilM 
p(R(Y)); 

IF  QtW)  THEN  Y  «-  W; 

END 

where  Q(W)  is  an  expression  containing  calls  to  boolean  procedures  indicated 
(syntactically)  by  the  presence  of  the  special  W-variables  (Section  2,  Rule  RO). 

There  are  many  heuristics  in  the  system  to  reduce  the  number  of  program 
variables,  i.e.  y’s  and  w’s  generated,  to  select  the  relevant  portion  of  Q  to  be  used  in 
conditional  assignment  statements,  to  generate  simple  assignment  statements  (whose 
right  hand  sides  are  functional  terms  composed  from  functions  in  Ihe  frame)  instead  of 
conditional  assignments,  and  to  eliminate  unnecessary  assignment  statements  in  the 
assembled  program.  These  may  all  be  classified  as  optimizations,  some  of  which  are 
done  as  the  "WHILE"  loop  is  assembled  and  others  during  a  iator  optimization  phase. 

6.3  UPDATING  THE  STATE 

After  the  while  statement  has  been  generated,  the  system  updates  the  state.  If 
an  explicit  output  assertion  S  is  given  then  the  rule  of  invariance  is  applied  in  the 
same  manner  as  with  the  postcondition  of  a  primitive  procedure.  In  the  absence  of  an 
output  assertion,  a  special  update  procedure  runs  the  loop  interpretively  on  the  state 
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until  the  goal  G  becomes  true.  The  resultant  state  is  used  in  further  planning  This 
latter  method  is  useful  when  the  global  effects  of  the  loop  computation  are  so 
extensive,  or  even  unpredictable,  that  an  explicit  specification  of  S  is  difficult.  It  may 
result  in  excessive  update  computation,  particularly  when  loops  are  nested. 

6.4  AN  EXAMPLE 

As  an  example  of  "while"  loop  generation  consider  the  task  of  generating  a 
program  to  compute  the  value  of  n  factorial  for  some  positive  integer  n  where 
multiplication  is  not  a  primitive  operation  but  is  done  by  repeated  addition.  The  Frame 
for  tnis  problem  is  shown  in  figure  10.  Also  used  is  the  primitive  procedure  for 
assignment  used  in  the  example  in  Section  3.  To  achieve  the  goal  "FACT(X0,N)n  the 
system  applies  the  iterative  rule  TRACT.  The  premises  are  achieved  according  to 
Section  6.1  which  results  in  an  application  of  another  iterative  rule  TPROD.  The 
premises  of  TPPOO  are  achieved,  the  "inner"  loop  assembled  and  optimized  and  state  is 
updated  with  respect  to  the  output  assertion.  The  assembled  while  loop  is  appended 
to  the  iteration  step  program  for  TFACT.  The  "outer"  loop  is  then  assembled  and 
optimized  and  the  state  further  updated  reflecting  the  total  state  transformation  of  an 
execution  of  the  nested  loop  program. 

Tho  output  program  after  optimization  with  statements  labeled  according  to  their 
source  of  generaton  in  the  algorithm  is  shown  in  figure  11.  Note  that  successive 
values  of  the  program  variables  are  obtained  by  simple  assignment  statements  rather 
than  by  conditional  assignment  as  described  in  the  algorithm.  This  is  the  result  of 
applying  system  heuristics  which  are  able  to  use  the  arithmetic  operations  PLUS  and 
AUiJi  which  are  primitive  functions  in  the  frame,  to  replace  the  conditional 


assignments. 
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RELATIONS 

DEFINITION 

FLUENT 

PARTIAL 

UNIQUENESS 

VTACT(X  Y) 

“The  value  o  t  Y  factorial  lc  X" 

TRUE 

FALSE 

VFACI( •,*) 

C  ( X ,  Y ) 

"The  contents  o f  variable  X  Is  Y" 

TRUE 

FALSE 

C  X.* 

FACT  X , Y) 

,vThe  variable  X  contains  Y  factorial" 

TRUE 

IALSE 

FACT  X,*) 

vproduct;x,y.z) 

"X  Is  equal  to  the  product  of  Y  and  2" 

TRUE 

FALSE 

FALSE 

INTECER(X) 

"X  Is  an  Integer" 

FALSE. 

FALSE 

FALSE 

ISVAR(X) 

"X  Is  a  variable" 

FALSE 

FALSE 

FALSE 

NEWVAR ( X ) 

"X  Is  a  new  local  variable" 

TRUE 

FALSE 

FALSE 

»(X,Y) 

"X  equal*  Y" 

TRUE 

IALSE 

FALSE 

AXIOM 

ANTECEDENT 

CONSEQUENCE 

TAFACT 

f-(V9,l)A-(Vl0.1)} 

V  VFAa((DIV  VJ  V10),(SUBI  VIO)); 

VF  ACT ( V9, Vlf ) ; 

TAPROD 

1-(v5.£>)a-(v^  .*5)} 

V PRODUCT i  V5 ,  V'.  ,  V} ) ; 

V  VPROUUCT( (MINUS  V5 , VJ ) , (SUBl  V6),V}); 

SriPL'FH-XTIOS  RUFFS 

AT* D i  i SUB1  X))  X 
(SUB l ( AUDI  X))  .X 
MINUS, PLUS  X  Y)Y)  -.X 
(DIV  PROD  X  Y)Y)  -.X 


HJNCTION  OUTPUT  SYNTAX 

ADD l  X)  -  (X  +  1) 

(Sl’Bl  X)  »  (X  -  1) 

PLUS  X  Y)  -  (X  +  Y) 


Figure  10 
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ITERATIVE  KH.ES 


RULE  NAME 

rasis  condition 


INVARIANT 


TRACT _ 

NEW  VAR  vy  )A  INTEGER  V-. 
AVEACT  VS- .  )AC  {  vy .  vr 

ac(  vy  tvC) ; 

c  w.vlf5)AC  v; , V9 ) 

AVlACT(\V,Vlf  ; 


ITERATION  STEP 

COAL 

TEST 


C (V! , (AUDI  Vlp) )A 
P  RODUCT  { V  j  ,  vl.  ,  ( ADD  1  V 1 0 ) ) ; 

EACT  V.5.V-0 ; 

-»-(vl>!,\ft); 


OUTPUT  ASSERTION 


C ( V ,  ( E AC  VI.)); 

. . . 


TPROD _ _ _ 

NEWVAR(  Vl*  )AC  V4  ,t) 

ac(vi  ,>",): 

c(V*  ,v6)ac  vl  ,V5) 
AVPRODUCT  V5,V'  ,  V})  ; 

C(VL , (AUDI  VC) ) 

c ( v  1 ,  (plus  V,  ,V3) ) ; 

PRODUCT v Vl, V?, V3 ) ; 

-i*(v6,V2)  ; 

C(Vl  ,  (PROD  VT? ,  V^ ) ) ; 


Figure  10  -  continued 
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PROCl (X0  N) 

ISVAR(Xji) ;  INTEGER(N)  ; 
COMMENT 

INPUT  ASSERTIONS: 

NONE 

OUTPUT  ASSERTIONS: 

C(X0  (FAC  N) )  ; 

BEGIN 

p(P) (TFACT ) -  X/>  -  1; 

Initial  Assignment -  Yh  —  1 ; 

(TFACT) 

WHILE  -1=  (Y4  N)  DO 

p (p) (tprod) 

Initial  Assi 

p(R)  (TPROD) 

UPDATE  Assig 
(Optimiz 

UPDATE  Assignment  (TFaCT) -  X>6  *-  Y2  ; 

END 

END 


p(R) (TFACT) 


Figure  11 
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7.  PROGRAMMING  AIDS 

The  complexity  of  programs  that  can  be  generated  using  the  system  is  increased 
by  some  simple  facilities  described  in  this  section.  The  capabilities  discussed  here  are 
incremental  extension  of  a  current  program,  use  of  a  program  library,  and  expansion  of 
assumptions. 

The  system  enables  a  user  to  plan  incremental  extensions  of  a  program  simply 
by  saving  each  completed  program  segment  A  and  its  output  state  0  in  a  stack.  The 
user  may  then  pose  a  new  goal  G  and  solve  the  problem  0{B}G.  The  composition  A;B 
will  then  be  output.  He  may  choose  to  st art  from  any  previously  saved  state  and 
associated  program  segment. 

7.1  PROGRAM  LIBRARY 

When  a  program  A  has  been  generated  to  solve  P{A}Q,  the  user  may  request 
that  it  be  "generalized"  and  filed  in  the  program  library  where  it  may  be  accessed  by 
the  subgoalrr  (similar  use  of  a  lit  rary  in  robot  planning  is  reported  in  [Fikes.Hart,  and 
Nilsson  1972]). 

Generalization  is  a  process  which  constructs  a  procedure  declaration  for  the 
library  as  follows.  Let  I  and  0  be  the  input-output  assertions  comDuted  for  A  during 
its  construction.  We  assume  Pal,  O-QaO’,  and  1{A}0.  The  non-fluent  conjuncts  of  I  are 
taken  as  the  type  declarations,  their  variables  being  the  parameters  of  the  new 
procedure.  These  actual  parameters  are  replaced  throughout  I{A}0  by  new  formal 
parameter  variables.  An  entry  of  the  form: 

((<procname>  <goal>  <effects>  <type  conditions>  <state  condition>)<body>) 
is  made  in  the  library,  where  <procname>  is  a  name  and  parameter  list,  <goal>  is  Q, 
<effect$>  is  O’,  <body>  is  A,  and  it  is  assumed  that 

<type  conditions>  a  <state  condition>{<procname>}<goal>  a  <effects> 
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Library  procedures  are  used  during  program  generation  by  matching  on  the 
^oal*  then  establishing  the  <type  conditions>  and  <state  condition$>  as  subgoals  in 
that  order.  If  the  conditions  are  satisfied  then  the  instantiated  <body>  is  included  in 
the  program.  The  system  requirement  of  achieving  the  input  assertions  and  processing 
the  output  assertion  during  update  for  a  program  taken  from  the  library  prevent  its 
incorrect  use  in  a  particular  program.  There  is  no  attempt  to  organize  the  library  for 
efficient  selection;  the  system  merely  tries  all  library  procedures  before  any  frame 
rule. 

As  an  example  of  program  assembly  using  the  library  consider  the  task  of 
building  a  tower  to  reach  an  object,  i.e.  achieve  "HAS(M9)H.  Use  will  be  made  of  a 
library  program  to  find  and  put  on  shoes  which  achieves  WEARINfM, SHOES),  previously 
generated  using  the  same  Frame.  The  generated  program  is  then  extended 
interactively  by  posing  a  new  goal,  AT(M,P). 

A  robotics  frame  for  this  problem  is  shown  in  figure  12,  and  the  generated 


programs  in  figure  13. 
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RELATIONS 

FLUENT 

PARTIAL 

UNIQUENESS 

KOBOT  X) 

"X  Is  a  robot" 

FALSE 

FALSE 

FALSE 

BOX  {  X ) 

"X  is  a  box" 

FALSE 

FALSE 

FALSE 

AT(X.Y) 

"X  is  at  location  Y" 

TRUE 

FALSE 

AT(X.*) 

ON  X,Y) 

"X  is  on  Y" 

TRUE 

FALSE 

ONfX. • ) 

HAS  X,Y) 

"X  has  possession  of  Y" 

TRUE 

FALSE 

FALSE 

STACKED  X.Y.Z) 

"X  is  stacked  on  Y  at  location  Z" 

TRUE 

FALSE 

FALSE 

INSTACK, X.Y' 

"X  is  In  a  suck  At  location  Y” 

TRUE 

FALSE* 

INSTA  'X(X, •) 

STACKHE ICHT X.Y' 

"the  stack  height  at  location 

Y  is  X" 

TRUE 

FALSE 

STACKHE  1  CIITi  *.Y) 

HEICHT'X.Y) 

"X  is  positioned  at  a  height 
of  Y" 

TRUE 

FALSE 

HEiC!IT(X,*' 

TO  P  \  X ,  V ) 

'*X  is  the  top  object  in  stack 
at  Y" 

TRUE 

FALSE 

TOPC.Y) 

H1ENUF  X.Y.Z) 

"X  is  AS  high  AS  Y  At  Z” 

TRUE 

FALSE 

FA1.SF 

HOIJITNC  .X.Y.Z) 

"X  is  holding  Y  at  location  Z" 

TRUE 

FALSE 

HOLDING)*. #.Z) 

CHAIK'X) 

"X  is  a  chair" 

FALSE 

FALSE 

FALSE 

CLOTHES  (.X) 

"X  is  an  article  oi  clothing" 

FALSE 

FALSE 

FALSE 

ui®lh(x.y) 

"X  is  under  Y" 

TRUE 

TRUE 

FALSE 

WEARING  X.Y) 

"X  is  wearing  clothing  Y" 

TRUE 

FALSE 

FALSE 

FOUNOCX.Y) 

"X  found  Y" 

TRUE 

FALSE 

FALSE 

•(X.YI 

"X  la  equal  to  Y" 

FALSE 

FALSE 

FALSE 

ABOVE*. X,Y,Z) 

"object  X  is  above  robot  Y  at  Z" 

TRUE 

FALSE 

FALSE 

ABOVE  X.Y.Z' 

"object  X  is  above  object  Y  at  Z" 

TRUE 

FALSE 

FALSE 

BOTTOMBOX  X.Y) 

"X  is  the  bottom  box  at  Y" 

TRUE 

FALSE 

FALSE 

BOTTOMBOXl  X.Y.Z 

"X  is  the  bottom  box  at  Z  under  Y" 

TRUE 

FALSE 

FALSE 

BELOW*  fX.Y.Z  ) 

"object  X  is  below  robot  Y  at  Z" 

TRUE 

FALSE 

FALSE 

BELOW  X.Y.ZI 

"object  X  Is  below  object  Y  at  Z" 

TRUE 

FALSE 

FALSE 

SUPPLY  X) 

"the  supply  is  at  location  X" 

FALSE 

FALSE 

FALSE 

NEXTBOX  X.Y) 

"X  is  the  next  box  alter  Y" 

TRUE 

FALSE 

FALSE 

F igure  1 2 
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PRIM  1 11 VE  PKOCKDIHE _ PRE-CONDITIONS _ POST-COND1T  DNS 

travel  (Rl, LI, L?)  ROBOT  Rl  !\AT;R1 ,  LI  )AHEICHT(R1  ,fi) ;  AT(R1,L2); 

"Ri  c  revels  from  LI  to  IP" 


move  Rl ,01 ,L1 ,L2) 

"RI  moves  01  Iron  LI  to  L2" 


ROBOT  RI)ABOX'01)nAT{01.Ll)A-ilNSTACKrcl,Ll)A  AT(01  ,L?  )AAT(RI  ,LP  ) ; 
CLOTHES  i OJ  )AWEAR  1 NC i R 1 ,0.J )AAT (R 1 , L 1 ); 


•  teck,R1.0P,01,Ln 

"Rl  stack*  OP  on  01  at  LI" 


Climb  R1.01.L1) 

"Rl  climb*  01  at  LI" 


unclimh  Rl ,0c , L 1 ) 

"Rl  uncllab*  X  at  LI" 


atepoff  R 1,01. 11) 

"Rl  *tep*  off  01  at  LI” 

reach (Rl ,01 ,L1 ) 

"Rl  reaches  01  at  LI" 


ROHOT  Kl)AbOX  01  )ABOX  ,02  )A^(01 ,02  )AAT(01  ,L1  )a  STACKED  0?  ,01 , LI  )A 

AT  COP  ,  LI  )AAT ;  Rl  ,1.1  (AHOLD  INC  'Rl  ,02 ,L1 )A  STACKHElCHTl  (EVN(ADLl  HI)), LI' 

HEICHT,R1.?)aON;R1.01,L1)a-STACKED(03,01,L1)  ATOP(Cl.Ll); 

ASTACKHE I CHT .HI ,L1) ; 

ROBOT  Rl'AABOVER  01,Rl.Ll)AATfRl,Ll)A  ONR1 ,01 ,L1A 

-sISSTACK ,01 ,L1 )v  heicht;ri,(evn(addi  HI))); 

(  STACKED ! 01 ,0? ,L1 )A0N(R1 ,0P ,L1 ))A 
REQUEST  HE ICHT . Rl ,H1 )) ; 


ROBOT  R1)A BE LOUR  01 ,R1 ,L1)AAT(R1 ,L1 )A 
REQUEST ;  HE  ICHT .  R 1 ,  H 1 ))  A 
REQUEST ( STACKED  0? ,01 ,L1 )  )A 
ON  Rl ,0? ,L1 ) ; 

■(HI  j6)AHE1CHT (Rl , 1 )A0N( Rl ,01 ,L1 ) ; 


ROBOT  Rl )AAT( 01 ,LI )AH IENUF (Rl ,01 ,L1 ) ; 


ON' Rl ,01 ,L1 )A 

HEIGHT (Rl , ' EVN . SUB1  HI))); 


H£ICHT(R1,H1)A 

-ON(Rl.Ol.Ll); 

HAS (Rl ,01 ) ; 


11  ft (Rl ,01 ,L1 ) 

"Rl  lifts  01  at  LI" 


robot, ri>abox;oi)aat(oi,li)aat(ri,li)a  holdinc(ri,oi,li); 

-IINSTACK(OI.LI); 


find  R1.01.L1) 

"Rl  finds  01  st  LI" 


ROBOT ( R 1 )ACHA 1R ( 02 )AAT(02 ,L1 )AAT(R1 , LI  )A  FOUND (Rl ,01 ) ; 

UNDER, 01 ,02); 


put_onLRl,01) 

"Rl  puts  on  01" 


ROBOT ( Rl )ACLOTHES ( 01 JAFOUND (Rl ,01 ) ; 


HEARING(Rl.Ol); 


AXIOM _ 

TABOVER 
TABOVE 
TBELUR 
T  BE  LOU 

TROT 

TROTU 

TNEXT 

T1NSTACX 


ANTECEDENT 


CONSEQUENCE 


-lON  Rl ,02 ,L1  )v lON  R1,C3,L1)AABOVEC01,OJ,L1))  ; 

•  ( 01 .0}  }v  l  STACKED  .  02  ,03  ,  LI  JAABOVE  ,  01 .02  .  LI )  J  ; 

ONRl.OP.LDAgELOU'Ol.OE.Ll); 

•(01 .  03  )v  l  STACKED,  03.fi3  ,Ll )  ABE  LOW  01,02, L1)J  ; 

TOP. 03 , LI JABOTTOMBOXU  01 ,03 ,L1 ) ; 

STACKED  03,OU,Ll)ASTACKED;Ov,OP,Ll)v 
STACKED  03,01,Ll)A-^TACKEDI01i.X.Ll)v 
BOTTOMBOXU  01,0b ,Ll); 

SUPPLY(Ll)AAT(Ou,Ll); 

TOP '02, LI  )abELOW(01,02,L1  ) ; 


ABOVERiOl.Rl.Ll); 
ABOVE (01, 03. LI); 
BELOURCol.Rl.Ll); 
BELOW i 01 ,03. LI); 
BOTTOMBOX.Ol ,  LI ) ; 
BOTTOM  BO  XU,  01 ,03.  LI); 

NEXT  BOX  Cm  ,03) ; 
INSTACK (Cl ,L1 ) ; 


DEFINITION 

HE  ICHT  (01  ,H1)ASTACKHE  ICHT  (HI ,  LI  )ATOP’,OC  ,  LI  )AON(  Rl  ,02  ,L1 )  ■  HIENUF.Rl.Ol  ,L1) 


Figure  12  -  continued 
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ITERATIVE  RILE 

BASIS  CONDITION 

INVARIANT 

ITERATION  STEP 

OUT  PITT 

TUP 

REQUEST  MEIUlTiKl.M.-)) 
ACE  ( HP  )V 

l BOTTOM BOX  'OJ, LI) 
AON(RI.0i,Ll Ij; 

ON,R1,01,L1)A  0N(RI,0?,U); 

STACKED, o:  , 01, LI) 

VTOPvQI.Ll); 

HElCHT(Rl.Hi);  — 

TDOWN 

C2(H1)A 

REQUEST  HEIGHT  K1,H  )) 
ACTIH.’.Hl); 

ON(R1,01.L1)A  ON,Rl,a  ,L1); 

STACKED,  01  .X.  LI) 

•  BOTTOMBOX  01. LI); 

HEIGHT ,RI .HI ) ;  — 

-- 

TSTA 

STACKED  X .01 , LI  5 

AON  Rl.X.Ll); 

T0P(0’,L1)A 
STACKHE ICHT 
(H.T.L1)A 

NEXT  BOX  (OB .  03 ) ; 

HOLDING, RI.O..L1) 
AHE1GHT. Kl .HP ) 
ASTACKED , 0C ,0* ,L1 ) ; 

STACKHE ICHT 
(Ml .LI) ; 

— 

INITIAL  STATE 


c,)~?XiB2iAB0X  B  ,AU0X  B\'\l»XfB6)ABOX,iMABOX(B7)AAT(M,P)AATiB,U)AAT(B2.SU>e)AAT(B5  SU>C)AA1(B?  SLOC'A 

,SU)C,A*T  AATB'.SLOC  ASUPPLY  SLOC)ASTACKHEICHT  (0.U  )AH£ICHT{M.0)AHE  1CHT  B  k  lACLOTHES  SHOES  ia  ' 

CHAIR , CHAIR  1 ;ACHA IK , CHAIRS )AAT  SHOES .CORNER  ;AAT i CKA 1H1 .CORNER  JAAT .CHAIRE  .CORNER ) ;  ’ 


RECURSIVE  RILES:  CLIMB  .TABOVE  .TBELOW ,  TBOTU 


PAIRWISE  1NEQUA' 1TIES:  tr*vel(Rl , •, • ; .move (R1 ,01 .  •.  •) 
STACK(R1,»,«,L1) 


Figure  12  -  continued 
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PROCI (M  SHOES ) 

R0BOT  M  , CHAIR  CHAIR.’);  CLOTHES  SHOES)- 
COMMENT  ’ 

INPUT  ASSERTION: 

«E  IC.HT  M  0  )AAT,M  P)AAT  CHAIR?  CORNER) 
OUTPlT_ASSKRTION: 

AT  M  ('OltNER)AI  OUNI)  M  SHOES  (AWEAR INC  (M  SHOES’- 
COMMENT 

PRO''  ,i TTLE1 PTS _TO_ACil  I  EVE  FOUND  M  SHOES  )  • 
BEGIN  “  ' 

TRAVEL  M  P  CORNER  ; 

IP  "'UNDER  SHO’S  CHAIR.  )  THEN 
PROG? ,  M  SHOf.S 
ELSE 
BEGIN 

FIND  M  SHOES  CORNER 
END 

PUT  ON  M  SHOES 
END 


Aiacmbled 

from 

Library 


PROC }  i  M  B 
ROBOT  M);BOX  B 
COMMENT 


’  iCLOTHES  SHOES),CHAIR  CHAIR.  );BOX  B-. )  .SUPPLY  .SI.OC ) ;  BOX  & 


-> 


AHFIrHT^ M  C  (CHAIR  CORNER) AAT  v  BE  SLOC 
OLTPUT  ASSERT^  ,T(C  U'MTlB6  SL0C)MT’^  SL0C> 


I ’  ,/'nT(P’  U.Ar.T(B4  U)/\STACK£D(B4  B7  U)AAT(B6  U) 

AFOU^'m'sho^  lir3TACKHElr'"T<4  UVNHAS(M  B)AHEIGHT<M  0) 
AFOLNO  M,  SHOES  ,  AWEARINC  M.  SHOES );  AAT  BJ  U)  AST  ACRED  (B3  Bf  U); 


TRAVEL  M  I '-CORNER) ; 

IF-.  UNDER  S  IOES  CHAIR.  )  THEN 
PROC  (M  , HOES  I 
ELSE 
BEGIN 


FIND  M  SHOES  CORNER) 
END 


I  -T  ON  M  SHOES  , 

"TiCCVtr'M  Corner  sloc); 

MOVE  M  B'  SLOC  U  , 

TRAVEL  M  U  SIOC 1  , 

MOVE  M  b*.  SLOC  U  ; 

LIFT  M  hi.  U) ; 

CLIMB  M  H  '  U)  i 
STACK  M  BE  B7  U); 

CLIMBIM  BE  U); 

Y3  -  2; 

YE  -  I*  ; 

IF  NEXT  BOX  WE  YE)  THEN 
ZE  -  WE  ; 

WHILE -.STACKHEICKI  E  U)  DO 
BECIN 

ZJ  -  ADDI  Y;); 

Yl  -  YE; 

IF  STACKED  Y1  W1  U)  THEN 
Z1  -  Wl; 

WHILE  -.HEIGHT  (MI)  DO 
BECIN 


UNCLIMb  M  Yl  U), 

Y1  -  Zl; 

IF  STACKED  Yl  WI  U)  THEN 
Zl  -  WI ; 

END 


STEPOFF (M  B7  U); 
TRAVEL (M  U  SLOC); 
MOVE'M  Z4  SLOC  U) ; 


)  I  BOX  '  B3 ) ; 


Figure  13 
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LIFT(M  ZL  U); 

CLIMB(M  B  U); 

Y?  -  B7 ; 

IF  STACKED  W2  Y?  U)  THEN 
Z?  -  wr ; 

WHILE  -JIEICHTvM  YJ)  BO 
BEGIN 

CLIMB, M  ZD  u); 

Y2  -  Z2 ; 

IF  STACKED  >W?  Y?  U)  THEN 
Z?  -  UP; 

END 

STACK  M  ZL  YL  U); 

Y3  -  ZJ ; 

Y4  -  ZL ; 

IF  NEKT BOX  WL  YU )  THEN 
ZU  -  W'.  ; 


END 

CLIMBfM  B;  U); 

REACH  HI  Vk 
Y5  -  BJ ; 

IF  STACKED  Y5  W5  U)  THEN 
Z5  -  W5 ; 

WH.LE  -HEICHTjM  I  U)  DO 
BEGIN 

I’NCLIMB  M  Y5  V); 

Y5  -  Z5; 

IF  STACKED  Y5  W5  U)  THEN 
Z5  -  W> ; 

END 

STEPOFF  M  B’  U); 

TRAVEL  M  L’  P  j  : 


END 


Figure  13  -  continued 
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7.2  EXPANSION  OF  ASSUMPTIONS 

A  basic  capability  for  structure  programs  is  provided  by  interactively  allowing 
the  user  at  any  level  in  program  generation  to  define  a  primitive  procedure,  P{p)Q,  as 
an  assumption.  The  program  generator  will  then  use  p  as  usual  except  at  each  point 
of  call  to  p  in  the  program  the  current  state  1’  and  current  goal  G  will  be  saved.  The 
triple  <p,I\G>  is  placed  in  a  stack  of  subtasks  for  later  expansion. 

When  a  program  containing  assumed  primitive  procedures  has  been  generated, 
the  user  is  given  the  list  of  assumptions  his  program  depends  on  and  allowed  to 
selectively  expand  them  in  terms  of  lower  level  procedures.  For  the  subtask  <p,I\G>, 
the  state  is  initialized  to  V,  the  frame  may  be  changed,  G  is  given  as  the  goal, and  a 
body  for  the  procedure  p  is  generated. 

Consider  the  example  given  in  Section  6  of  computing  the  value  of  n  factorial 
where  multiplication  is  not  a  primitive  operation.  The  initial  frame  is  the  same  except 

that  in  place  of  an  iterative  rule  for  multiplication,  there  is  an  assumed  primitive 
procedure 

ISVARfV  1  ){times(V  1  ,V2,V3)}PR0DUCT(V1  ,V2,V3), 
where  PR0DUCT<V1,V2,V3)«C(V1(<PR0D  V2,V3)). 

The  program  generated  using  this  frame  is  given  in  figure  14.  To  expand  the 
non-prim.t.ve  procedure  "times(Vl,V2,V3)"  the  full  frame  including  the  iterative  product 
rule  is  given  and  the  sub-program  generated  is  shown  in  figure  15. 

In  the  current  implementation  it  is  assumed  tht  the  expanded  sub-programs  will 
have  no  side  effects.  However  this  assumption  could  be  removed  by  a  mechanism 
similar  to  checking  rejoin  conditions  for  contingency  programs  (Section  5.4). 

To  develop  a  useful  structured  programming  system  interaction  appears 
essential  along  with  further  study  about  how  humans  do  (or  should  do)  programming. 
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l  KOC  t,  X.' 

ISVAK  <;  ;INTKGEK(N  ; 

COJHENT 

INPl'I  ASSERTION': 

NO  Nr. 

OUTFIT  ASSKKUON: 

c  x;  f  ac  n  ; ) ; 

COMMENT 

THIS  PROGRAM  RELIES  ON  THE  EOlLlAMNC  ASSITFT  IONS  : 


TIME'S 
EEC  IN 
X.*  -  1  , 

Yl  -  1. 

WHILE  -  >  Yl  Nj  IX) 
BEGIN 

Yl  -  Yl  +  I; 

TIMES  Xi  X„*  Yl 
END 


END 


Figure  14 


TIMES  X.)  Yl  Zl) 

ISVAK  XC) ; 
comment 

INPUT  ASSEkTION: 

NONE 

OITPIT  ASSERTION : 

CiXC  (PKOD  Yl  Zl ) ) ; 
BECIN 
X.’  -  7, 

Y  -  7, 

WHU  E  ->  "(Yl  Yl  DO 
BECIN 

Y2  -  Y+l , 

x7  -  x7-+z  1 ; 

END 

END 


Figure  15 
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a  CORRECTNESS  Or  TH£  FORMAL  ALGORITHM 

The  basic  problem  solving  algorithm  implemented  in  the  system  is  that  ol 
prob  em  reduct, on  subgoal, ng  w.lh  backtrack.  In  this  section  the  formal  algor, thm  will 
be  given  and  a  proof  of  its  correctness  sketched. 

»  1  BACKTRACK  PROGRAMMING 

Backtrack  programming  describes  an  exhaust, ve  search  procedure  appropriate 
for  solving  problems  ot  the  torm: 

G,ven  a  collection  ol  sels  X,,X2,.,X„  (goals  to  be  ach.eved),  select  a  sequence  of 
elements  one  irom  each  set  (a  way  of  ach.ev.ng  each  goal),  such  that  some 

criterion  (unction  f(X|.x;,.,x„)  ,s  m  .ximiaed.  In  general  t  may  be  numerical  valued  or 
simply  have  the  values  of  either  -success"  or  -tailor.-  for  any  sequence  ks 

n,  and  ,t  ,s  possible  to  determine  whether  or  not  a  parhal  solution  ,s  inherently 

subopt, mal,  i.e  ,(  there  does  no,  exist  a  successful  x,<  X,  given  the  current  choice  ol 

*1. -.**  1 

To  control  such  a  search  a  program  must  have  the  abilities  to  enumerate  the 
alternatives  to,  selection  at  the  kth  level,  eg.,  (enumerate  function),  select 

one,  say  (choose  lunct.on),  and  repeat  this  process  at  successively  higher  levels, 

k“'  k*2 . Unl'1  Cl,h0r  ,t'e  "lh  "'O'  IS  attained  or  a  partial  so,ut,on  (xpx;,.. . . 

PS  n,  is  reached  that  is  inherently  subopt, mal,  ,.e„  no  selection  can  be  made  at  level  p 
that  IS  correct  with  respect  to  the  previous  choices  already  made.  In  the  latter  case 
•he  program  must  ‘backtrack-  to  a  previous  level,  e  g,  k,  a,  which  .  W  selection 
(different  Irum  previous  level  k  selection)  can  be  made  that  achieves  a  correct  kth 
level  solution  (unchoose  function).  The  process  then  continues  ,n  the  -torwarq- 
d, section.  Ultimately  either  an  nth  level  sequence  is  (ound  that  ,s  satisfactory  or  the 
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operation  of  the  program  has  proven  that  a  solution  does  not  exist,  i.e.,  the  program 
has  "backtracked"  to  the  Oth  level  and  has  failed  to  solve  the  problem. 
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8.2  TRAVERSING  THAND-OR-ANO  SUBGOAL  TREES 

Programs  are  generated  by  using  rules  and  axioms  to  prove  that  the  output 
program  transforms  the  initial  state  into  one  in  which  the  given  goal  condition  is  true. 
Frame  rules  act  as  partial  functions  on  the  domain  of  possible  states,  defined  only  on 
•hose  states  in  which  their  premisses  a  e  true  and  transforming  them  into  states  in 
which  their  postconditions  (or  goal  conditions)  are  true. 

In  figure  16  is  given  the  subgoal  tree  traversed  during  the  solution  of  the 

example  problem  given  in  Section  2.  Goal  nodes  are  labeled  with  the  goal  and  an 

nleger  indicating  the  order  of  achievement  in  the  depth-first  search.  Rule  nodes  (used 

to  expand  the  goals)  aro  labeled  witn  the  rule  name  and  an  integer  indicating  the  order 

of  successful  application.  In  the  tree  absence  of  angle  marks  indicate  OR  connection,  a 

sing  -  angle  mark  indicates  AND  connection  and  double  angle  marks  indicate  THAND 
connects  n, 


PROBLEM  1 :  THAND -OR -AND  TREE  SEARCH 
Figure  fb 
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Program  generation  is  done  by  computing  on  a  triple  <G\1’,A>,  where  G’  is  the 
subgoal  to  be  attempted  next,  1'  s  the  current  state  and  A  is  the  current  program 
segment  For  each  rule  used,  an  instantiation  of  the  associated  program  construct,  if 
any,  is  added  to  A  using  rule  R2.  The  general  form  of  rules  to  expand  goals  (as 
explained  in  Section  2.1)  is, 

Hi . Ki 

K 

The  instantiation  of  program  constructs  is  built  up  in  a  substitution  oc  that 

replaces  variables  in  the  *rame  rules  by  terms  from  the  initial  state.  For  any  rule  if 

Koc-G’  then  that  rule  is  applicable  to  the  achievement  of  G’  and  the  premisso*, 

Hiot,...,HnoC  are  the  subgoals  whose  solution  implies  G\  We  assume  for  the  computation 

of  o i  that  variables  in  different  applications  of  the  same  rule  are  distinct. 

The  syntax  of  assertions  used  in  rules,  axioms,  definitions  and  state  descriptions 

is  given  in  Section  3.1,  Consider  the  restrictions  that  the  exclusive  or  is  used  only 

as  a  top  level  connective  in  disjunctive  postconditions  of  primitive  procedures  and  the 

thand  &  is  only  used  to  connect  the  premisses  of  an  iterative  rule  (which  in  fact 

follows  the  current  implementation  though  its  effect  can  be  gained  in  any  rule  using 

advice).  Then  for  any  <goal  node>,  say  G’  in  state  I’,  the  THAND-OR-AND  solution  tree 

Tr  that  may  be  rooted  at  G’  is  described  by  the  following  grammar  Gr: 

<goal  node>  <true  goal>|<prim  proc>|<def >|<it  rule>|<undetermined  goal> 

<prim  proc>  <assertion> 

<def>  <assertion> 

<it  ru!o>  (<basis>  a  <invariant>)  &  <it  step> 

<basis>  ::■»  <assertion> 

<invariant>  <assertion> 

<it  step>  <assertion> 

<assertion>  <disjunction>|<disjunction>  a  <assertion> 

<di$junction>  <goal  node>|<goal  node>  v  <disjunction> 
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where  if  G’  is  a  <true  goal>  then  OcOFVF  c  GV  and  Undetermined  goal>  ,s  as 
cnfmed  in  Section  5.  A  full  specification  of  the  formal  algorithm  for  processing 
undetermined  goals  would  include  a  formalization  of  the  subproblem  stack,  the  methods 
choosing  contingency  goals,  assembly  of  conditional  statements,  keeping  track  of 
the  goals  in  the  scope  of  a  contingency  goal  and  contingency  state  manipulation. 
However  since  the  concepts  involved  are  described  quite  completely  in  Sections  5  and 
9  they  will  not  be  dealt  with  further  here. 

The  definition  of  an  achieved  goal  node  G’  in  a  THAND-OR-AND  tree  is: 

(1)  If  G’  is  a  'true  goal>  then  it  is  achieved, 

(2)  if  G’  has  OR  subgoals  then  it  is  achieved  iff  at  least  one  of  its  subgoals 
is  achieved, 

(3)  If  G’  has  AND  subgoals  then  it  is  achieved  iff  all  of  its  subgoals  are 
achieved  and  remain  true  in  the  resulting  state 

(4)  If  G  has  THAND  subgoals  then  it  is  achieved  iff  all  of  its  subgoals  have 
been  achieved. 

Further  details  on  these  kinds  of  problems  may  be  found  in  [Nilsson  1971], 

If  G’  is  achieved  under  (2),  (3),  or  (4)  (i.e.  by  rule  application),  then  V  is  updated 
by  Inv(KoC,P)  and  a  procedure  call  or  a  while  loop  may  be  appended  to  A. 

Search  algorithms  of  this  type  may  be  conveniently  implemented  using  any  of 
the  new  languages  that  directly  support  subgoal  tree  generation,  backtrack,  and  a  data 
base  [Hewitt  1971,  Sussman  and  Winograd  1972],  [Rulifson  et  al.  1972]. 
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8.3  LABELED,  ORDERED  SUBGOAL  TREES 

Before  we  can  consider  correctness,  the  notion  of  a  labeled,  ordered  THAND-OR- 
AND  subgoal  tree,  say  Tr,  must  be  formalized.  Let  Tr  be  a  solution  tree  generated  by 
the  algorithm  during  a  successful  program  generation,  S  be  the  set  of  nodes  in  Tr,  rnd 
R^SXS  be  a  partial  ordering  on  S.  Let  J  be  another  relation  on  S  defined  in  terms  of  h 
by: 

xJy  iff  {Vx,y)[xRy  a  -  yRx  a  (Vz)[z><y  a  zRy  =>  zRx]}. 

For  x,y<$,  xJy  means  that  y  is  the  R-direct  descendent  of  x,  or  x  is  the  R-direct 
ancestor  of  y. 

DEFINITION  A  structure  Tr  -  <S,R>  is  a  tree  if  the  nllowing  properties  are  satisfied: 

(1)  There  is  a  root  element  of  the  tree,  i.e.,  (jx),(Vy)[y(S  ^  xRy], 

(2)  For  x,y,z  <S,  if  xJz  and  yJz  then  x«y 

DEFINITION  A  structure  Tr  -  <S,R,L>  is  an  ordered  tree  if  the  following  properties  are 
satisfied: 

(1)  Tr  -  <S,R>  is  a  tree, 

(2)  For  each  x<S,  L  is  a  total  ordering  of  {y  :  x Jy }, 

(3)  For  each  x,y,z  <S,  if  xLy  and  yRz  and  x*<y  then  xLz, 

(A)  For  each  x,y,z  <S,  if  xLy  and  xRz  and  xHy  then  zLy. 

The  relation  L  orders  the  nodes  of  Tr  in  depth-f  rst  achievement  order,  e.g., 

7 

/\ 

3  6 

/V  /  \ 

12  4  5 

Let  V  be  the  set  of  goals  achieved  in  Tr  instantiated  by  oc.  The  function  f  will  be 
called  the  labeling  function. 
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DEFINITION  A  structure  Tr  -  <S,V,R,L,f>  is  a 
properties  are  satisfied: 

(1)  Tr  -  <S,R,L>  is  an  ordered  tree, 

(2)  The  function  f  maps  $  onto  V. 


labeled,  ordered  tree  if 


the  following 


Let  Gr  be  the  grammar  describing  solution  subgoal  trees  and  let  Tr  -  <S,V,R,L,l>  be  e 
labeled,  ordered  tree. 


DEFINITION  Tr  is  a  labeled,  ordered  THANO-Oft-AND  subgoal  tree  rooted  at  G*  In  Gr  it 
the  following  properties  are  satisfied: 

(1)  If  x<S  is  the  root  of  the  tree  <S,R>  then  f(x)  -  G\ 

(2)  H  3y(S  such  that  f(y)  /  \  0nd  xRy  and  xHy  then  f(x)  is  not  a  <true 
goal>(i.e.  x  is  not  a  leaf  node). 

(3)  If  yi,-,yn  *  {y  :  Kjy}*  where  y^y I  i<j  then  there  exist  some  frame 
rule  having  postcondition  (or  goal)  f(x)  and  premisses  f(yi), ...  ,f(yn). 

Vv»  will  refer  to  such  trees  as  solution  trees  in  the  next  section. 
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8.4  CORRECTNESS 

For  any  output  program  generated  by  the  system  the  associated  solution 
(sequence  of  axioms  and  rules  used)  provides  a  proof  within  the  logic  of  programs 
given  in  Section  2  that  the  program  satisfies  the  given  input-output  asser  ions. 
Because  of  implementation  limitations,  heuristic  system  methods,  and  consistency 
requirements  in  a  fr*mo  definition  whicn  the  user  may  violate  a  system  generated 
program  may  in  fact  be  incorrect.  However  we  will  show  that  from  a  solution  tr «. o  Fr 
generated  by  the  formal  algorithm  to  solve  the  problem  <I,G>  with  properties  as 
defined,  a  correctness  proof  of  the  solution  can  be  given.  Conditions  for  correctness  of 
the  procedure  for  generating  conditional  statements  was  given  in  Section  5. 

We  may  show  by  induction  on  the  ordering  of  nodes  in  Tr  that  the  oiitpi* 
program  A  solves  the  problem,  i.e.  L(F)  ||-I{A)G  by  showing  it  to  be  true  for  each 
subgoal  and  partial  program,  i.e.  if  xtS  is  the  root  of  the  tree  and  f(x)  -  G  then  for  any 
y<S  such  that  xRy  ,  L(F)  ||-I{A’}f(y),  where  A’  is  the  partial  program  in  the  triple 
computed  by  the  achievement  of  f(y). 

Let  G’  -  f(x)  be  such  that  Vy(S  xLy,  then  G’(V  is  a  <true  goal>,  i  e.  it  labels  the 
leftmost  leaf  node  of  Tr,  and  L(F)  ||-Ir>G’. 

As  an  induction  hypothesis  assume  that  for  an  arbitrary  G’-f(y)  such  that  y  is 
not  the  root  of  Tr  that  LtF)  ||-I{A’}f(y).  We  will  then  show  that  this  must  imply  L(F)  ||- 
I{A”}f(z),  where  yLz  and  either  zJy  or  (3x)[xJy  a  xJz  a  ->  zJy],  where  A’  and  A”  are  the 
generated  program  segments  in  the  associated  triples. 

Consider  the  cases  for  the  triple  <G\1\A’>, 

(1)  If  G’  labels  a  leaf  node  of  Tr  then  L(F)  ||-I’  u  F  o  G’  and  the  state  and 
program  segment  are  unchanged  by  its  achievement.  This  implies  L(F)  ||-I{A’}G\ 

(2)  If  G’  labels  a  non-leaf  node  x  of  Tr  then  we  have  the  following  subcases, 
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An  instance  of  a  primitive  procedure  rule  P*(p«)Q«  is  applied  to  achieve  G\  i.e. 

0*  =  O'.  Its  application  is  justified  by  the  change  o,  variables  rule  M  By  hypothesis 
■•uf  I-  Po£  since  property  (3,  p,  th>  definition  „  ,  tr„  „  sa,is(|ed  ^  ru|e 


Of 

I” 


consequence  .mpl.es  L(F)  ||-  l'(p*)Q*  and  invariance  implies  1(F)  IKtlwjr,  where 
lnv(Qcc,l ).  By  the  rule  of  composition  R3  we  may  compose  A’  with  p«  end  by  the 


induction  hypothecs  we  conclude  that  L(F)  ||-l(A'lp«)r,  where  I"  o  G’. 

For  the  cases  in  wh,ch  instances  of  definitions  or  iterative  rules  are  applied  to 
■Chieve  G\  the  , eduction  step  may  also  be  proved  establishing  L(F)  ||-  ,(A)G  More 


formal  details  may  be  found  in  [Buchanan  and  LucKham  1970)  This  discussion  was 
intended  to  justify  fhe  forma,  methods  impiemented  in  «.  system  by  showing  that 
under  certein  assumptions  about  solution  trees  a  correctness  proof  can  be  given. 
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9.  SYSTEM  DESCRIPTION 


This  section  will  document  the  system  implementation  to  the  end  that  its 

operation  might  be  better  understood  and  to  the  conceptual  level  that  would  be 

reasonably  helpful  in  designing  a  more  expanded  system.  The  system  was 

implemented  in  LISP  using  MICRO-PLANNER  primitives  [Sussman  and  W, nograd,  1971], 

with  which  we  will  assume  the  reader  has  some  familiarity.  MICRO-PLANNER  was  a 

very  preliminary  version  of  PLANNER  [Hewitt,  1972].  Many  of  our  programming 

triumphs  modifying  MICRO-PLANNER  and  writing  new  primitives  are  no  longer 

necessary  in  light  of  the  new  languages  now  available  [Sussman,  1 972],[Rulif son  et  al. 
1972], 

9.1  OVERVIEW  OF  INTERACTIVE  SYSTEM  USE 

The  interactive  decision  points  and  programs  called  at  the  top  level  are  shown  in 

figure  1  .  (This  is  a  how  chart  of  the  top  level  LISP  function  SUBGOAL.)  The  system 
basically  has  three  segments: 

U)  a  Frame  translation  program  (see  Section  9.2), 

(2)  a  set  of  programs  for  program  generation  called  from  SUBGOAL  and  using  a 
translated  Frame, 

(3)  a  set  of  primitives  that  modify  and  extend  MICRO-PLANNER. 

The  user’s  interaction  witn  the  system  shown  in  figu.e  17  is  informally 
described  by  the  following  procedure: 

'1/  A  filename  may  be  given  as  an  argument  to  SUBGOAL.  If  the  file  contains  a 
Frame  definition  then  the  translator  is  read  in,  the  Frame  definition  translated 
and  loaded.  If  the  file  contains  a  translated  Frame  then  it  is  simply  loaded.  If  no 
filename  is  given  then  a  Frame  definition  to  be  translated  and  loaded  is  g:ven 
interactively  from  the  terminal. 
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(2) 

(3) 

(4) 


When  prompted  by  the  system,  the  user  inputs  ,  goal  ,0  be  achieved  by  the 
Pi  ogram  to  be  generated. 

»  the  user  desires  to  give  advice  to  the  system  relative  to  the  given  goal  then 
the  advice  system  is  called. 

The  subgoal, ng  system  uses  the  translated  Frame  to  attempt  to  generate  a 

program  achieving  the  goal.  It  unsuccessful  the  user  may  try  again  w,*h  more 
advice  (go  to  (3)). 


«>  If  reio,n  conditions  (see  Sechons  5.0  and  9.0)  „e  pending  tor  this  generated 
procedure  then  they  are  tested  for  satisfaction.  I,  they  are  no.  satisfied  then 
the  user  may  attempt  to  extend  the  procedure  to  yield  a  state  in  which  they  ure 
true.  I.  he  chooses  no.  to  do  th,s  or  the  system  ta,ls  in  ,ts  attempt  then  an 
error  ex, I  ,s  substituted  for  any  call  to  that  procedure  ,n  its  trunk  program. 

(6)  "  ,he  “r  elCC,S'  ,he  w  "’V  he  optimized  according  to  some  simple 

criteria,  e.g.  elimination  of  dead  assignment  statements  and  reduction  of  the 
number  of  program  variaoles. 

m  The  user  may  then  choose  to  have  the  generated  program  generalized  and  bled 
in  a  program  library. 

(8)  The  program  is  then  displayed  for  visual  inspection. 

(9)  If  there  are  conditional  statements  (see  Section  9.5)  then  the  user  may  elect  to 
do  contingency  pro, mam  generation.  If  so  then  the  state,  goal  pending  and 
answer  is  initialized  from  the  stack  of  contingency  tasks  (go  to  (3)). 

(10)  If  any  assumed  primitive  procedures  occur  ,n  the  generated  program  the  user  is 
informed  and  may  structurally  (see  Section  9.7)  develop  each  assumption 
procedure  call  by  generating  a  program  whose  input  and  output  assertions 
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match  the  pre  and  postconditions  of  the  assumed  primitive  procedure  (Initialize 
the  state  and  go  to  (3)). 

(11)  The  program  may  now  either  be  incrementally  extended  from  the  current  state 
by  giving  an  additional  goal  (go  to  (2))  or  any  previously  completed  program 
segment  and  final  state  may  be  returned  to  and  extended. 

In  Appendix  fa  is  an  example  of  an  interactive  dialogue  including  a  Frame 
translation  and  program  generation. 


r 
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9.2  PROCEDURAL  REPRESENTATION  OF  A  FRAME 

In  Section  8  the  basic  problem  reduction  subgoaling  algorithm  was  given  and  in 
Section  4  associated  problem  solving  processes  using  Frame  information  were 
described.  In  this  section  a  more  detailed  description  of  the  function  and  form  of  a 
translated  Frame  will  be  given.  The  translation  and  use  of  iterative  rules  anc  the 
generation  of  conditional  statements  will  be  given  in  Sections  9.6  and  9.5  respectively. 
9.2.1  SOME  ELEMENTS  OF  MICRO-PLANNER 

Assuming  general  familiarity  with  MICRO-PLANNER  we  will  briefly  describe  a  few 
basic  primitives  and  theorem  lypes  as  used  in  the  system  description  (see  [Sussman 
and  Winograd,  1971]  or  Baumgart,  1972]).  In  the  current  implementation,  <pjttern> 
will  represent  seme  relation.  In  a  more  general  treatment  <pattern>  could  represent 

ah  arbitrary  Boolean  expression  of  relations.  Pattern  matching  is  restricted  to  simple 
unification. 

The  control  structure  is  a  backtrack  stack  interpreter  consisting  of  a  program 
representation,  a  processor  state,  a  processor  and  a  push  down  stack  of  all  previous 
states  the  procesror  has  been  through  since  the  beginning  of  a  particular  computation. 
The  processor  may  backtrack  to  a  previous  state  and  exhaustively  search  a  subgoal 
tree  in  a  depth-first  manner  trying  all  possible  variable  bindings  and  applicable 
theorems  to  return  success  ultimately  to  the  top  goal  node. 

(1)  (THGOAL  <pattern>  <recommendation>).  If  no  <recommendation>  is  given  then 
THGOAL  simply  searches  the  data  base  for  an  assertion  that  matches  the 
pattern.  If  it  finds  one,  it  succeeds  and  carries  out  the  unification  substitution 
for  any  variables  in  the  pattern,  otherwise  it  fails.  If  a  <recommendation>  is 
given  :t  will  be  of  the  form,  (THT6F  <filter>),  where  <filter>  is  the  name  o*  a 
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unary  LISP  fund, on  that  selects  from  candidate  THCONSE  theorems  to  be  called 
after  a  data  base  search  has  failed.  The  atom  THTRUE  is  the  always  true  tiller, 
i.e.  allows  any  matching  theorem  to  be  tried. 

(2)  (THNOT  <argumont>).  THNOT  fails  it  its  <argument>  succeeds,  other-’,,  it  fails. 

(3)  (THASSEKT  <skeloton>  <recommendat,o„>).  The  <skeleton>  may  either  be  a 
theorem  name  to  be  put  on  a  ready-to-use  list  or  an  instantiated  relation  that  is 
to  be  added  to  the  data  base.  THASSERT  fails  only  it  it  tr.es  to  assert  a 
<skeleton>  already  e„st,ng  either  on  the  ready-to-use  list  or  in  the  data  base. 
If  a  <recommendafion>  is  given  it  will  be  of  the  form,  (THTBF  <filter»,  where 
<hlter>  is  the  name  ol  a  unary  LiSP  function  that  selects  from  candidate  THANTE 


theorems  to  be  called. 


m  (THERASE  <skeleton>  <recommendat,on>).  The  <skeleton>  may  either  be  a 
theorem  name  to  be  removed  from  a  ready-to-use  Us.  or  an  instantiated  relation 
that  is  ,o  be  removed  from  the  data  base.  THERaSE  fails  only  if  „  ,ries  ,o 
remove  a  <ske,e.on>  that  does  no,  exist  either  on  the  ready-to-use  list  or  in  the 
data  base.  If  a  <recommendation>  is  given  ,1  will  be  of  the  form,  (THTBF 

<f.lter>),  where  <filt.r>  is  tho  name  of  a  unary  LISP  function  that  selects  from 
candidate  TH  RASING  theorems  to  bo  called. 

<5>  (THOR  <argl>...<,rB„>.  THOR  succeeds  if  one  of  its  arguments  succeeds  where 
evaluation  is  left  to  right.  This  construct  is  used  to  implement  logical  function. 
(THSETL)  <var,>  <e,>  ...  <e„>).  This  primitive  assigns  the  value  of 

expression  <e,>  ,0  the  variable  <var,>  for  i-l„.,„.  The  variable  is  no, 
evaluated.  This  assignment  is  undone  if  failure  backs  up  to  it  A  simple 

extensirn  provided  the  function  THSET  which  dues  evaluate  its  first  argument 
but  is  otherwise  equivalent  to  THSETQ. 
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(7)  Theorems.  Theorem:.  are  pattern  evoked  ana  have  the  format: 

(DEFPROP  <name>(<type>  ''>/arlist>  <pattern>  <body>)  THEOREM) 
where 

<name'>  is  an  atomic  theorem  name, 

<type>  is  the  theorem  type, 

<varlist>  is  the  list  of  variables  used, 

<pattern>  is  a  relation  for  pattern  match  invocation, 

<body>  is  a  sequence  of  statements  having  the  syntax  of  the  body  of  a  LISP  PROG. 

The  list  (<type>  <varlist>  <pattern>  <body>)  is  of  course  attached  to  the  property  list 
of  <name>  under  the  indicator  THEOREM  as  a  result  of  the  DEFPROP. 
lnere  are  three  types  of  theorems: 

(a)  Consequent  theorems  (THCOMSE)  are  called  by  a  match  between  the 
pattern  of  a  THGOAL  statement  and  ♦he  theorem  pattern. 

(b)  Erasing  theorems  (THERAS1NG)  are  called  by  a  match  between  a  relation 
skeleton  of  a  THERASE  statement  and  the  theorem  pattern. 

<c)  Antecedent  theorems  (THANTE)  are  called  by  a  match  between  a  relation 
skeleton  of  a  THASSEKT  statement  and  the  theorem  pattern. 

If  a  theorem’s  pattern  is  matched  by  the  appropriate  calling  statement  then  the 
<varlist>  is  bound  and  body  is  executed  such  that  for  ine  theorem  to  succeed  each 
statement  must  succeed  (return  non-nil)  with  the  capability  for  backtracking  to 
discover  an  instantiation  and/or  subgoal  tree  rooted  at  that  statement  that  returns 
successfully.  THERAS1NG  and  THANTE  theorems  do  not  return  a  value  and  are  assumed 
to  succeed  as  it  affects  the  success  of  the  calling  statement;  however,  THCONSE 
theorems  return  either  a  success  or  a  failure  value  that  determines  the  success  of  the 
calling  statement. 
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9.2.2  SPECIFICATION  AND  BASIC  FUNCTIONS  OF  FRAME  RULES 

When  a  primitive  procedure  is  initially  input  the  following  information  is  put  on 

the  property  list  of  the  atomic  procedure  name: 

(1)  preconditions, 

(2)  postconditions, 

(3)  argument  list, 

(4)  whether  or  not  the  procedure  is  an  assumption, 

(5)  whether  or  not  the  procedure  is  recursive, 

(6)  inequalities  desired  in  argument  positions, 

(7)  indicator  of  rule  type,  i.e.  primitive  procedure. 

Except  for  argument  list  specifications  ((3)  and  (6)),  the  analogous  information  for 
axioms  and  detinit'ons  is  initially  stored  the  same  way. 

On  the  property  list  of  each  predicate  symbol  is  stored  the  following: 

(1)  argument  list, 

(2)  whether  or  not  the  relation  is  a  fluent, 

(3)  whether  or  not  the  relation  is  partial, 

(4)  argument  positions  having  the  uniqueness  property. 

The  internal  data  structure  used  to  represent  assertions  after  input  is  a  list  of 
lists  where  the  interpretation  of  juxtaposition  of  elements  is  conjunction  at  the  top 
level  and  alternates  between  conjunction  and  disjunction  at  successive  levels  of 
nesting.  At  the  bottom  level  a  literal  is  represented  as  a  list  of  negation  sign  (if  any), 
predicate  symbol  and  the  arguments.  For  example  the  assertion, 

P(X)  v  Q(Y)  A  -R(X,Y)  A  S(Z,X)  v  (T(Z)  a  M(V)}; 
is  represented  as 

(((P  X)  (Q  Y))  ((-  R  X  Y)X(S  Z  XX«T  Z))((M  V))))). 

This  internal  representation  is  clearly  adequate  for  assertions  input  using  the 
syntax  given  in  Section  3. 

A  translated  rule  for  a  primitive  procedure  contains  the  basic  functional 
segments  shown  in  figure  18.  An  actual  example  of  a  primitive  procedure  definition 
and  its  translated  form  is  given  in  Section  9.2.3.i.  The  pattern  is  the  postcondition 
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achieved  by  an  application  of  the  procedure.  The  interactive  program  allows  the  user 

• 

to  enter  the  Advice  System  then  return  for  continuation  of  subgoaling.  Trace 
information  of  current  path  and  goals  pending  is  displayed.  Nonfluent  preconditions 
are  achieved  first  then  the  fluent  preconditions.  The  mechanism  for  achieving  a 
conjunction  of  fluent  goals  is  described  in  Section  9.2.3.2.  Processing  to  make  the 
state  consistent  with  the  postcondition  next  to  be  asserted  is  carried  out.  The 
instantiated  procedure  call  is  appended  to  the  oartially  generated  program  followed  by 
processing  for  collecting  input-output  assertions,  forming  correct  block  structure  in 
nested  conditional  statements  and  diagnostic  output  to  the  user. 
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CALLING  PATTERN 

INTERACTIVE  AND  TRACE  PROGRAMS 
ACHIEVEMENT  OF  NON-FLUENT  PRECONDITIONS 
ACHIEVEMENT  OF  FLUENT  PRECONDITIONS 
STATE  CONSISTENCY  PROCESSING 
ASSERTION  OF  POSTCONDITIONS 
ASSEMBLY  OF  PROCEDURE  CALL  INTO  PROGRAM 
MISCELLANEOUS  PROCESSING 

(INPUT-OUTPUT  ASSERTION,  BLXK  STRUCTURE,  DIAGNOSTICS) 


FUNCTIONAL  SEGMENTS  Or  RULES  FOR  PRIMITIVE  PROCEDURES 

FIGURE  IB 
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9.2.3  FRAME  TRANSLATION 

A  Frame  defined  using  the  lang  lage  described  in  Section  3  is  translated  into  a 
set  of  LISP  functions  and  MICRO-PLANNER  theorems  that  form  the  basis  for  the 
subgoaler.  In  particular  for  each  rule  or  axiom,  one  or  more  MICRO-PLANNER  THCONSE 
theorems  is  constructed,  for  each  distinct  predicate  symbol  a  THERASING  theorem  is 
generated  to  implement  the  conjunction  connective.  The  initial  state  description  is 
converted  to  assertions  placed  in  the  data  base. 

9.2.3. 1  TRANSLATION  PROCEDURE 

The  translation  is  carried  out  according  to  the  following  procedure: 

(1)  The  appropriate  input  device,  i.e.  terminal  or  disk,  from  which  to  read  the  Frame 
definition  is  s9lrcted. 

(2)  For  each  rule  defined  the  information  listed  in  Section  9.2.2  is  input  and 
internalized. 

(3)  The  initial  state  expressed  in  the  syntax  of  conditions  is  input  and  internalized. 
(A)  For  each  predicate  symbol  used,  the  information  listed  in  Section  9.2.2  is  input 

and  internalized. 

(5)  The  user  may  request  context  linking  or  performance  statistics  to  be  gathered. 

(6)  Algebraic  simplification  rules  may  be  given  of  the  form, 
t  -»  t\  where  t,t’  are  terms, 

which  are  used  to  reduce  t  to  t’  should  t  occur  in  an  argument  of  a  relation  in  a 
THGOAL  statement,  e.g. 

(MINUSfPLUS  X,Y)Y)  -»  X, 

where  X  and  Y  may  be  bound  to  arbitrary  terms  to  which  the  rules  will  be 
applied  recursively. 
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(/)  Conversion  rules  for  more  readable  output  syntax  for  functions  occurring  in  the 
generated  program  are  specified  in  the  form, 
t  "  °c  ,  where  t  is  a  term  and  u.  is  an  expression  in  the  new  syntax, 
which  are  used  to  produce  the  final  output  form  of  the  generated  program,  e.g. 
(PLUS  X  Y)  -  (X  ♦  Y), 

where  X  and  Y  may  be  bound  to  arbitrary  terms  to  which  the  rules  will  be 
applied  recursively. 

(8)  The  conjunction  of  literals  given  to  form  the  initial  state  is  asserted  into  the  data 
base  according  to  the  following  rules  giving  the  assertion  made  for  a  literal  I  as 
a  function  of  being  negated  or  partial. 

(a)  If  I  -  P(tl,...tn),  for  some  predicate  P,  then  assert  P(tlr..,tn), 
tb)  If  I  ■  •'P(t  i,...,tn)  and  P  is  total  then  assert  nothing, 

(c)  If  I  -  -P(tl,...,tn)  and  P  is  partial  then  assert,  by  convention,  NP(tl,...,tn). 

(9)  For  each  predicate  symbol  used  generate  a  THERAS1NG  theorem  and  some  global 

variables  whoso  form  and  use  in  implementing  conjunction  are  described  in 
Section  9.2.3. 2. 

(10)  For  each  rule  defined,  a  THCONSE  theorem  i>  generated  implementing  the 
functions  shown  in  figure  13,  i.e. 

(o)  Tho  calling  pattern  is  the  rule  postcondition. 

(b)  For  each  total  precondition  literal  I  a  THGOAL  statement  is  generated 
according  to  tho  rules: 

(i)  If  I  “  P(tl,...,tn)  and  P  is  non  fluent  then 
"(THG0AL(P  oc(t  1  )...oc(tn)XTHTDF  FILTERAX))" 

where  FILTERAX  is  a  LISP  filter  function  which  permits  only  deduction 
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using  the  axioms  relative  to  the  current  state  and  oc  transforms  ti  into  « 
valid  MICRO-PLANNER  term. 

(ii)  If  I  -  ->P(tl,...,tn)  and  P  is  non-fluent  then 
"(THNOT(THGOAL(P  oc(tl)...*(tn)XTHTBF  FILTERAX)))" 

(hi)  If  I  -  P(tl,...,tn)  and  P  is  fluent  then 
"(THGOAL(P  oc<tl)...oC(tn))(THTBF  FILTEROP))" 

where  FILTEROP  is  a  LISP  function  which  controls  the  choice  of  rules  or 
axiom*  enterea  on  the  basis  of  advice  given,  if  any. 

(iv'  If  I  ■  -P(t l,...,tn)  and  P  is  fluent  then 
"(THNOT(THGOAL(P  oc(tl)...oC(tn)XTHTBF  FILTEROP)))" 

A  Boolean  expression  of  these  statements  corresponding  to  the  precondition  is 
generated.  The  implementation  of  conjunction  and  other  functional  parts  of  the 
theorem  are  described  in  later  sections. 

(11)  The  translated  Frame  is  then  loaded,  i.e.  functions,  global  variables  and  theorems 
defined  and  theorems  asserted.  The  user  may  now  begin  program  generation. 

As  an  example  of  3  translated  rule  consider  the  primitive  procedure, 

ROB(R1)a-KILLED(R1)aAT(R1,L1)aCLEAR(L1,L2)vHASUMBRELLA(R1) 

AWALKADLE(Ll,L2){walK(Rl,Ll,L2)}AT(Rl,L2). 

which  translctes  into  the  Micro-Planner  theorem  shown  in  figure  19 

wh,ch  is  labeled  according  to  the  basic  functional  segments  described  in  Section  9.2.2 
and  shown  in  figure  18. 
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(T  TD 

(THCONO  ((NULL  (THU  WALTAOLEAPGS) I  T) 

(T  (THSETO  (THU  UALKABLEARGS)  (COR  (THU  UALKABLEARGS) )  T  TD) 

(THCONO  ((NULL  (THU  ATARGS  I )  T)  (T  (THSETO  (THU  ATARGS  I  ICDR  (THU  ATARGS) )  T  T)l) 

(THCONO  ((NULL  (THU  NKILLEDARGSI )  T) 

(T  (THSETO  ITHU  NKILIEOARGSI  (COR  ITHU  NKILLEDARGSI)  T  TD) 

(THCONO  ((THGOAL  (HASIHSRELI.A  (THU  Rl )  RD 

(THCONO  ((NULL  (THU  HASUHBRELLAARGS))  T) 

(T  (THSETO  (THU  HASUHBRELLAARGS)  (COR  (THU  HASUNBRELLfWRGSD  T  Till) 

IT  TD 

(THCONO  KTHOOAL  (CLEAR  ITHU  Lll  (THU  LZ)  Rll 
(THCANO  ((NULL  (THU  CLEAPAPGSD  T) 

(T  (THSETO  (THU  CLEARARGS)  (COR  (THU  CLEARARGSI)  T  TDD 

(T  TD 

(THCONO  I  ( THANO  (THASUAL  (THU  LZD  (THASUAL  (THU  LID)  T)  (T  I  THTR.JL  1 1  > 

(THCONO  ( 1  EQUAL  (THU  LZ1  (THU  LID  (  THFAIL 1 1  (T  TD 

ITHCDNO  ((THGOAL  (AT  (THU  Rl  I  (THU  01)  Rl)  (THSETO  (THU  AT  INST i  (LIST  I1WI  Rll  (THU  011111 
(T  TD 

ITHCDNO  ((THGOAL  (AT  (THU  Rll  (THU  01)  Rl'  <  TIC  RASE  (AT  (THU  Rl)  (THU  01)  R)  (THTBF  TMTRUED1 
IT  TD 

(THCONO  KTHERASE  (WRONG  PATH))  (THFAIL  TICOREUD  (T  TD 
(THSET  (CAR  (THU  ANSI) 

(CONS  (CONS  IOUOTE  WALK)  (LIST  (THU  Rl )  UHU  Ll)  (THU  LZD)  (EU<N.  (C«<  (THU  ANSIllD 
(THSETO  (THU  DGL1TS1  ICONS  ICDAR  CT)  (THU  D6L1TS)  1) 

(TMASSCRT  (AT  (THU  Rll  UHU  LZ)  Rll 
(THSETO  (THU  ASSERTLUSI 

(CONS  (LIST  (LIST  (QUOTE  ATI  UHV  Rll  (THU  LZ)  (OUOTE  RD  (LIST  (QUOTE  A)  IOUOTE  Afll 
UHV  ASSERTLUSI  I ) 

(PRINT  (REVERSE  (EVAL  (CAR  (THU  ANSI)))) 

(SETO  GANS  (REVERSE  (EVAL  (CAR  UHV  ANSIID) 

(CONO  ((■GREAT  (LENGTH  CANS)  I  LENGTH  LGANSD  (SETO  LGWIS  GANS) )  (T  TD 
( THDO  (TERPRID 

(CONO  MEO  (OUOTE  IF)  (CAOAR  CT ) I  (ELSE CLAUSED  (T  (THSETO  CT  (CDR  CT1  T  Tllll 


Figure  19 
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9-2.3. 2  IMPLEMENTATION  OF  CONJUNCTION 

The  basic  idea  for  implementing  the  achievement  of  a  conjunction  of  goals,  Gj  a 
G2  a... a  G„,  is  to  prevent  the  falsification  of  any  G|,  1  jS  i  S  n,  until  all  G(  arc  achieved, 
thus  creating  a  state  in  which  the  conjunction  is  true. 

For  each  fluent  predicate  symbol,  say  P,  used  there  is  a  global  variable  createc, 
i.e.,  PARGS,  which  is  initialized  to  the  value  NIL  and  will  hold  a  stack  of  instances  of  P 
that  are  to  be  preserved  during  the  achievement  of  the  conjunction.  This  is  done  by 
adding  the  instance(s)  of  the  literal(s)  whose  achievement  causes  the  current  goal  in 
the  conjunction,  say  G|  ,  1  <,  i  <  n,  to  be  true  to  the  appropriate  stack  before  G*  i  is 
attempted.  When  the  entire  conjunction  has  been  achieved  the  literals  for  each  G|  in 
that  conjunction  are  popped  from  the  stack.  The  LISP  function  that  generates  this 
code  is  recursive  for  arbitrary  Boolean  conditions  satisfying  the  syntax. 

A  THERAP1NG  theorem  is  also  generated  for  each  P(Xl,...,Xn)  as  follows: 

(DEFPROP  PGREML1N 
(THERAS1NU  (Xl  .Xn) 

(P  (THV  X1UTHV  Xn) 

(THCOND«MEMBER(LIST(THV  X1UTHV  Xn)) 

(THV  PARGS)) 

(THASSEHTfWRONG  PATH))))) 

(THEOREM), 

where  THV  is  a  MICRO-PLANNER  indicator  that  its  argument  is  a  variable. 

If  some  instance  P(tl,...,tn)  is  to  be  erased  to  maintain  state  consistency  (see 
Section  9.2.3.4)  then  the  act  of  erasing  will  call  PGREMLIN  which  will  assert  the  flag 
(WRONG  PATH)  into  the  data  base  if  (tl,...,tn)  is  a  member  of  PARGS.  Such  an  assertion 
is  responded  to  in  the  THCONSE  theorem  in  which  the  erasure  occurred  by  generating 
the  following  statement  after  the  erase  statement: 

(THCONCX(THERASE(WRONG  PATH)XTHFAIL  THEOREM)XT  T)). 
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The  THERASE  statement  in  the  above  will  succeed  only  if  (WRONG  PATH)  existed 
>n  the  data  base  which  was  caused  by  an  invalid  erasure  detected  in  the  THERASING 
theorem.  The  flag  seems  necessary  since  success  or  failure  in  the  THERASING  theorem 
does  not  affect  the  success  of  the  THCONSE  theorem  causing  the  erasure.  The  failure 
of  the  THCONSE  theorem  will  force  the  system  to  try  to  find  another  theorem 
corresponding  to  another  rule  that  does  not  falsify  a  goal  in  the  conjunction. 
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9.2.3.3  CONTEXT  LINKING 

Thts  feature  discussed  in  Section  4  is  implemented  by  denoting  certain 
assertions  in  the  data  base  as  being  "hypothetical-  or  not  part  of  the  state  and  used 
only  in  connection  with  this  feature.  If  requested  MICRO-PLANNER  code  is  generated 

to  precede  the  achievement  of  the  precondition  goals  for  rules  and  axioms  and  tr 
carry  out  the  following  functions: 

(1)  The  precondition  goals  are  attempted  relative  to  the  hypothetical  portion  of 
the  data  base  only  to  determine  possible  variable  bindings. 

(2)  The  instantiated  precondition  goals  are  asserted  into  the  hypothetical  data 
base  for  use  in  descendant  rule  applications  in  the  subgoal  tree. 

following  the  achievement  of  the  preconditions  of  a  rule,  the  hypothetical  data 
base  is  restored  to  the  state  at  rulo  entry. 

9.2.3.4  UNIQUENESS  PROPERTIES 

Updating  the  state  is  discussed  in  Section  4  as  an  application  of  the  invariance 
rule.  Building  in"  axioms  defining  uniqueness  or  single  valuedness  of  certain  relation 
argument  position  has  proven  useful  for  state  consistency  processing. 

When  a  Frame  is  defined  an  argument  position  of  any  relation  may  be  designated 
to  be  unique  by  responding  to  a  system  query  with  an  asterisk  in  that  position. 
Multiple  argument  positions  may  be  so  designated. 

Before  an  instantiated  postcondition,  P(tlr..,ti,...,tn)  is  asserted,  contradictory 
litorals  in  the  data  base  are  removed.  For  each  position  designated  as  unique,  suppose 

the  ith,  the  goal  P(tl,„.,X . tn)  is  attempted  with  a  new  unbound  variable  in  the  ith 

position.  If  it  is  successful,  i.e.  X  is  now  bound  to  val(X),  then  P(tl,...,val(X),..»  Is 


erased. 


102 


SYSTEM  DESCRIPTION 


For  example  consider  the  predicate  AT(X,Y)  -  "Object  X  is  at  location  Y",  where 

both  argument  positions  are  unique,  i.e.  AT(*,*).  Then  in  the  state  update  portion  of 

the  theorem  the  following  code  is  generated: 

(THCOND«THGOAl(AT(THV  XXTHV  01))) 

(THERASE(AT(THV  X)(THV  DDXTHTBF  THTRUE))) 

(T  T» 

(THCONO((TH£RASE( WRONG  PATH)XTHFAIL  THEOREM)) 

(T  T)) 

(TrlCONO{(THGOAL(AT(THV  D2XTHV  Y))) 

(TH£RASE(AT(THV  D2XTHV  Y)XTHTBF  THTRUE))) 

(T  T)) 

(THCOND{(THERASE{WRONG  PATH)XTHFAIL  THEOREM)) 

(T  T)), 


where  D1  and  D2  are  unbound  variables. 

This  process  assures  that  if  the  state  is  consistent  with  respect  to  uniqueness 
properties  initially  that  this  consistency  will  be  maintained. 
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9.2.3.5  INTERNAL  REPRESENTATION  OF  GENERATED  PROGRAM 

A  program  segment  generated  by  the  system  is  represented  internJIy  in  a  list 

data  structure  satisfying  the  following  syntax: 

<program>  <block> 

<blocK>  ::*•  (<statemcnt-list>) 

<sfaiement-list>  <statemeni>|<statement><staiement-list> 

<$taiement>  (<procname><arglist>) 

<siatement>  (IF<condition>  THEN  <stctement>) 

<statemeni>  (IF  <condition>  THEN  <?taiement>  ELSE  <blocK>) 

<statement>  (WHILE  <condition>  UO  <blocK>) 

<siatement>  («-  <identifier><expression>) 

<procname>  <identif  ier> 

where, 

<ideniifier>  is  an  ALGOL  identifier, 

<expression>  is  a  LISP  functional  expression  in  prefix  form, 

<condition>  is  a  Boolean  expression  satisfying  the  syntax 
given  in  Section  3, 

<arglist>  is  list  of  arguments  each  of  which  is  either 
an  <identifier>  or  an  <expression> 


For  example, 

((<-  XO  1)(<-  Y1  INWHILE  -»>(Y1  N)  DO((<-  Y1  (ADD1  Y1))(TIMES  XO  XO  Yl))), 

is  the  factorial  program  in  Section  7.  The  above  syntax  speci'ication  describes  fhe 

structure  of  programs  that  may  be  generated  by  the  system. 

A  partially  generated  program  is  actually  maintained  in  a  stack  (a  list  with  access 
only  from  the  front)  of  "GENSYMed"  variables  which  is  poinied  io  by  a  global  variable 
ANS.  Each  iime  a  deeper  level  of  nesting  is  required,  i.e.  io  generate  ih©  body  of  a 
WHILE  loop  or  nested  conditional  statements,  a  new  variable  name  is  added  to  the  top 
of  the  stack  and  initialized  to  NIL.  Program  constructs  generated  at  this  level  are 
assigned  to  the  variable  at  the  top  of  the  stack  via  ANS  using  a  THSET.  When  a  level 
is  emerged  from  the  value  of  the  top  element  is  appended  on  to  the  value  of  the  next- 
to-top  element  and  the  siacK  is  popped. 

When  a  generated  program  is  output  it  is  translated  into  a  sjbset  of  ALGOL  In 
the  obvious  way  with  nesting  ;n  the  list  structure  corresponding  to  biock  nesting. 
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9.3  THE  STATE  UPDATING  METHODS 

The  updating  of  a  state  to  the  new  state  resulting  from  the  explication  of  a 
rame  rule  is  formulated  by  invariance  which  in  general  is  not  computable.  Some  of 
the  more  common  causes  of  inconsistencies  are  handled  by  the  uniqueness  probity 
mechanism  described  in  Section  9.2.3. 4.  Also  relevant  to  this  topic  is  the  discussion  of 
conjunction  implementation  in  Section  9.2.3.2.  As  explained  in  Section  6,  updating  the 
state  after  the  application  of  an  iterative  rule  may  be  either  impossible  or  impractical 
unless  the  user  provides  an  output  assertion  for  the  iterative  ruL-  in  which  case  the 
rule  of  tvariance  is  applied  as  witn  a  primitive  procedure  postcondition.  The  results 
of  applying  the  rule  of  invariance  are  influenced  by  the  fixed,  though  arbitrary, 
ordering  of  the  literals.  To  compute  Inv(I,Q)  a  subset  of  I  that  is  consistent  with  Q  is 
sought.  Since  in  general  the  choice  of  the  R((I  to  be  removed  that  prevents  the 
derivation  of  a  contradiction  witn  Q  is  '.at  unique,  the  ordering  determines  the  deletion, 
if  any. 

The  system  philosopny  bias  been  that  inconsistencies  are  of  no  concern  unless 
they  affect  the  correctness  of  the  generated  program.  Consistent  witn  this  is  a 
suggested  approach  that  if  an  inconsistency  is  detected,  say  during  some  axiomatic 
deduction,  that  *he  choice  of  literals  in  I  to  be  deleted  be  guided  by  the  following, 

(lj  1  ne  information  as  to  the  state  literals  used  to  prove  each  previous  goal  as  the 
program  has  been  generated  could  be  Kept  as  an  extension  of  the  input-output 
assert  computation  (described  later). 

(2)  The  literals  to  be  removed  should  be  those  that  least  affect  the  program,  i.o. 
either  those  as  yet  unused  or  those  most  recently  used  since  program  generation 
wouid  have  to  bacK  up  to  mat  point  then  proceed  after  the  deletion. 
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The  actual  Micro-Planner  code  eeneraled  to  update  the  state  after 
procedure  has  been  applied  is  shown  in  figure  19. 


primitive 
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9.4  CCMPUTA  i  ION  OF  INPUT -OUTPUT  ASSERTIONS 

The  computation  of  input-output  assertions  requires  the  extension  of  the 

MICRO-PLANNER  system  to  include  a  trace  stack  containing  rules  entered,  goals 

oendmg  ant'  goals  achieved  from  the  state,  i.e.  leaf  nodes  in  the  subgoal  tree.  This 

data  structure  is  in  addition  to  those  which  are  a  normal  pari  of  the  MICRO-PLANNER 

Processor.  This  stack  is  a  list  data  structure  satisfying  the  following  syntax: 

<trace-siack>  (<rule-list>) 

<rule-liet>  <rule-use>|<'ule-use><rule-!ist> 

<rule-use>  ((<rule-name><curreni-goal>)<flag-lisi><achieved-goal-list>) 
<achieved-goal-list>  ::■=  <achieved-goal>|<achieved-goal>vachieved-goal-list> 

where, 

<achieved-goal>  is  an  instantiated  precondition  subgoal  of  ihe  rule 
that  has  been  achieved  directly  from  ti  e  state, 

<current-goal>  is  the  current  precondition  subgoal  pending  in 

the  rule  tor  whose  achievement  rules  above  it  in  the 
stacK  have  ./den  entered, 

<flag-hst>  is  a  sequence  of  zero  or  more  hags  used  to  determine 
proper  block  nesting  in  conditional  statements 
(Section  9.5). 


For  example  the  trace  stack  may  appear  as, 

«<T1  (P  XI  a)XQ  a))((T2  (R  a  X2)XS  a  b))), 
a»  some  stage  of  a  computation  and  have  the  meaning, 

(1)  S(o,b)  has  been  achievod  from  the  str.te  in  T2, 

(2)  R(a,X2)  is  currently  pending  in  T2  and  T1  has  been  entered  to  attempt  its 
achievement, 

(3)  Q(a)  has  been  achieved  from  the  state  in  Tl,  and 

(4)  P(Xl,a)  is  currently  being  attempted. 

Ms  each  rule,  say  T,  is  successfully  applied,  before  its  <rule-use>  is  popped  from 
the  ‘race  stack,  its  <achieved-goal-list>  is  conditionally  added  onto  a  global  variable. 
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OBUTS.  Similarly  II  T  has  post  conditions  or  output  assertions  to  add  to  the  state  they 
are  conditionally  added  onto  a  global  variable,  ASSERTUTS.  The  condition  in  both 
cases  is  that  this  occurrence  of  T  will  appear  in  the  completed  subgoal  tree. 

For  any  generated  program  segment  A,  the  input  assertion  1.  and  output 
assertion  0,  may  be  computed  as  follows. 

(1)  By  compf'ing  each  addition  to  DBLITS  and  ASSERTLITS  in  order  of  ad-iition, 

those  members  of  DBLITS  that  became  true  in  the  state  as  result  of  an 

assertion,  <i,e.  are  members  of  ASSERTLITS),  <rom  a  previous  rule  are 
deleted. 

(2)  Redundancies  in  DBLITS  are  removed  yielding  the  input  assertion  Ia. 

(3)  The  output  assertion  0,  is  the  non-redundant  conjunction  of  all  members  of 
ASSERTLITS  that  are  true  with  respect  to  the  final  output  state  of  A. 
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9.5  GENERATION  OF  CONDITIONAL  STATEMENTS 

In  Section  5  the  algorithms  for  generating  conditional  statements  were 
described.  In  this  Section  some  of  the  details  of  the  implementation  will  be  given. 
Topics  to  be  covered  include  implementation  of  goal  nodos  cortaining  partial  relations, 
contingency  go?  selection  and  its  use,  and  associate  n  of  rejoin  conditions  with 
contingency  programs. 

9.5.1  GOAL  NODES  CONTAINING  PARTIAL  RELATIONS 

Let  L  be  a  precondition  subgoal  literal  containing  a  partial  relation.  The  code 

generated  to  attempt  achievement  of  L  is  of  the  form: 

(THCOND  ML)  T) 

(ct(-L)  (THFAIL)) 

(T  (UNCEHTlIT  L  SWITCH))) 

where  od(L)  is  the  appropriate  THGOAL  statement  from  for  L  as  described  in  Section 
9.2.3.1;  and  UNCERTLIT  is  a  LISP  function  or  two  arguments,  i.e.  an 
undetermined  literal,  L,  and  a  switch  value  indicating  whether  this  goal  occurs 
in  a  conjunction  (T)  or  in  a  disjunction  (NIL). 

The  function  UNCERTLIT  does  the  following: 

(1)  Appends  L  to  a  global  variable  UNCERLIST, 

(2)  Returns  not[SWITCH]. 

If  L  is  in  a  disjunction  then  UNCERTLIT  returns  NIL,  which  forces  the 

next  literal,  if  any,  to  be  tried  before  the  disjunction  is  declared  undetermined 
and  a  conditional  statement  generated.  See  definitions  in  Section  5.1. 

Either  as  the  last  statement  of  a  THOR  statement  (which  implements  disjunction) 
or  immediately  following  a  THCOND  statement  like  the  above,  a  call  to  the  LISP  function 
CONDSTAT  is  generated  wiih  behavior: 
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(1)  If  null[UNCERTLIST]  then  if  in  a  disjunction  return  NILfcauses  failure) 
otherwise  T(success). 

(2)  If  not[null[UNCERTLIST]]  then  generate  a  conditional  statement  and 
contingency  tasks  as  described  m  Section  5  and  detailed  in  So*.tion  9.5.2. 

For  example  the  disjunctive  goal  (see  example  in  Appendix  A;, 

VAR(x)  V  LP(x)  V  RP(x)  V  OP(x), 

will  result  in  the  ‘oilnwing  code  generated  by  the  frame  translator: 

(THOR(THCOND((THGOAL(VAR(THV  X)))T) 

((THGOAL(NVAR(THV  X)))  (THFAIL)) 

(T(UNCERTL(T(LIST(QUOTE  VARXTHV  X))T))) 
(THCOND((THGOAL(LP(THVX)))T) 

((THGOAL(NLP(THV  X)))  ( THFAIL)) 

(T(UNCERTLIT(LIST(QUOTE  LPXTHV  X))T))) 

(THCOND«THGOAL(kP(THV  X)))  T) 

«THGOAL(NRP(THV  X)))(THFAIL)) 

(T(UNCERTLIT(LIST(QUOT£  RPKTHV  X))T))) 

(THCOND((THGOAL(OP(THV  X)))T) 

«THGOAL(NOP(THV  X)))(THFAIL)) 

<T<UNCERTLIST<LIST<QUOTE  OPXTHV  X))T))) 

(CONDSTAT(THV  CGL)T)) 

where  CGI.  is  a  variable  having  as  value  the  post  condition  of  the 

rule  and  is  used  in  the  contingency  goal  selection  procedure.  The  goal 
-EMPTY(X), 

occurring  in  a  conjunction  will  result  in  the  generation  of  the 

following  code 

(THCOND«THGOAL(NEMPTY(THV  X)))T) 

«THGOAL(EMPTY<THV  X))XTHFAIL)) 

<T<UNCERTLIT<LIST<QUOTE  NEMPTYXTHV  X))NIL))) 

(CONDSTATEtTHV  CGL)NIL) 


This  code  generated  when  the  frame  is  translated  will  if  executed  at  program 
generation  time  call  the  necessary  construction  procedures  to  generate  conditional 


statements  as  further  described  in  the  next  section. 
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9.5.2  IMPLEMENTATION  OF  CONDITIONAL  STATEMENT  GENERATION 

When  a  goal  is  found  to  have  an  uidetermined  truth  value  as  defined  .n  Section 
5  and  implemented  according  to  Section  9.5.',  the  global  variable  UNCERTLIST  is  «nt 
the  list  of  undetermined  literals  (perhaps  moi  *  than  one  literal  if  G  is  a  disjunction 
The  following  procedure  is  then  carried  out: 

(1)  The  trace  stack  is  searched  from  the  top  (current  rule  entered)  to  find  thu 
pending  goal  of  smallest  scope  that  is  >'  lly  instantiated,  say  G»  and  to  i  at 
(RPLACA)  a  flag.i.e.  "IF",  for  each  member  of  UNDERTLIST  in  the  <rule-use> 
above  G*.  e.g.  for  rule  names  T  and  goals  pending  G, 

(..  <(T  G)  IF  ...)  «T’  G 

These  flags  in  the  trace  stack  will  signal  the  end  of  the  else  tlaL-uo  ant 
the  point  of  rejoin  for  the  contingency  programs  called  from  the 
conditional  sta  ement  and  generated  later. 

(2)  The  conditional  statement  is  generated  as  described  in  Section  5.2.  In 
particular  for  each  member  of  UNCERTLIST,  say  L,  a  new  procedure  name, 
say  p,  is  generated,  the  appropriate  siate,  say  S,  is  created  and  the  triple 
(p,S,G*)  is  placed  on  the  subproblem  stack. 

(3;  An  expression  of  the  form, 

(IF  iLi  THEN...UF  -L*  THEN  pk  ELSE  Pk  i)...ELSE) 

is  added  to  the  top  variable  in  the  ANS  stack.  Note  that  the  final  eise 
clause  is  left  empty  but  will  be  filled  in  with  what  was  called  the  trunk 
program  segment  in  Section  5.2. 

(A)  The  list  of  new  procedure  names  generated  in  step  (2)  is  "CONSed"  to  a 


global  variable  PkOCLIST. 
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(5)  A  new  answer  variable  name  is  generated  added  to  the  top  of  ANS  and 
initialized. 

(6}  Program  generation  continues  until  a  rule  has  been  successfully  applied 
that  has  some  IF  flags  on  its  <rule-use>  entry  in  the  trace  stack.  The 
following  steps  are  then  carried  out: 

(a)  Append  the  value  of  the  top  variable  in  ANS  to  the  next-to-the-top 
variable  and  pop  ANS.  (note:  This  places  the  trunk  program  as  the 
else  clause) 

(b)  Form  the  triple  ((CAR  PROCIIST)  DBLITS  ASSERTLITS)  using  current 
values  of  these  global  variable',  and  add  it  on  to  the  variable 
PROCDATA  to  be  used  later  to  compute  the  rejoin  condition  for  the 
programs  named  in  (CAR  PROCLIST) 

REMARK:  ANS  and  PROCLIST  are  managed  as  LIFO  stacks  which  correspond 
to  the  entering  and  exiting  of  blocks  in  the  generated  program.  This 
assures  that  the  correct  elements  will  always  be  at  the  top  of  the  stacks 
and  arbitrary  dooth  of  block  nesting  is  allowed. 

(7)  After  the  trunk  program  has  been  completely  generated,  each  triple  in 
PROCDATA  is  accessed.  Each  consists  of  a  list  of  procedure  names  having 
the  same  rejoin  point  in  the  trunk  program,  and  the  values  of  DBLITS  and 
ASSERTLITS  at  the  point  of  rejoin.  The  sufficient  input  assertion  for  the 
program  segment  from  the  point  of  rejoin  to  the  may  be  computed  by  by 
removing  from  the  values  of  DBLITS  and  ASSERTLITS  at  final  output  state 
their  respective  values  at  the  point  of  rejoin  then  following  the  algorithm 
described  in  Section  9.4.  This  input  assertion  must  be  provable  from  the 
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final  output  state  of  each  procedure  in  the  list  when  it  is  generated  (see 
Section  5.4)  and  is  stored  as  an  additional  element  of  each  associated  triple 
in  the  subproblem  stack. 
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9.6  ASSEMBLY  OF  WHILE  LOOPS 

In  Section  8  problem  reduction  search  in  a  FHAND-OR-AND  tree  was  described 
and  in  Section  6.1  the  subgoal  structure  of  a  node  expanded  using  an  iterative  rule 
was  given,  i.e.  the  premises  that  must  be  achieved  to  justify  the  construction  of  a  loop. 
The  subgoaling  system  provides  program  segments  and  substitution  information 
allowing  the  loop  assembly  phase  to  fully  satisfy  the  premises  and  construct  a  WHILE 
loop.  This  formal  algorithm  is  sketched  in  Section  6  and  now  the  methods  implemented 
will  be  considered  in  more  detail. 

The  inputs  to  the  loop  assembler  will  first  be  described.  Next  the  system 
methods  will  be  given  for  computing  the  successions  of  values  for  p-ogram  variables  to 
have  during  successive  iterations  of  the  loop.  Here  some  of  the  methods  are  decidely 
neuristic  iri  an  effort  to  reduce  the  number  of  generated  program  variable  and 
associated  assignment  statements.  Then  we  describe  the  generation  of  the  update 
assignment  statements  and  thoir  assembly  with  the  other  program  segments  to 
produce  a  complete  while  loop. 

9.6.1  INPUTS  TO  LOOP  ASSEMBLER 

Consider  an  iterative  rule  applied  to  achieve  I{?}G  defined  by  the  assertions 
P(basis),  Q(invariant),  Rfiteration  step  goal),  G(ruie  goal),  L(control  test)  and  Stoutput 
assertion)  and  whore  V  is  the  list  of  variables  in  Q.  The  inputs  required  for  loop 
assembly  are  as  follows. 

fl)  A  basis  program  segment  p(P)  is  given  that  rchieves  the  basis  condition 
from  state  I,  i.e.  I{p{P)}I’  and  I’  P. 

(2)  An  instance  QX.  of  the  loop  inva'iant  is  given  such  that  I’|-QX,  where  \=> 
{<vi+-si>,...,<vn«-sn>}.  The  substitution  \  is  actually  constructed  by  this 


114 


SYSTEM  DESCRIPTION 


deduction  and  will  be  used  to  provide  initial  values  for  system  generated 
program  variables  corresponding  to  certain  V|  determined  below. 

(3)  The  formal  algorithm  calls  for  the  generation  of  a  loop  body  program 
segment  p(R)  that  achieves  the  iteration  step  goal  from  the  state  QaL,  i.e. 
QaL{p(R)}1m  and  I"c  R.  This  is  to  assure  that  tho  generation  of  p(R)  did  not 
depend  on  particular  properties  of  individual  constants  not  shared  by 
others  of  the  same  type  in  the  domain  and  that  p(R)  would,  in  general,  be 
incorrect.  For  example  witn  respect  to  the  integers  zero  has  an  additive 
property  not  shared  by  other  integers,  i  o.  identity.  In  the  current 
implementation  p(R\)  is  generated  such  that  I’{p(R\)}r\  where  Q\aL\  are 
true  in  I’,  then  p(R\)  is  generalized  as  described  below. 

(4)  An  instance  Q\'  of  the  loop  invariant  is  given  such  that  1”’|-  QV,  where  V  - 
{<viHi>r..,<vn*-tn>).  Since  the  invariant  is  a  characterization  of  relations  in 
the  subset  of  the  state  relevant  to  the  iteration,  comparing  Q\  and  Q\’  will 
reveal  instances  of  value  "changes"  that  should  be  computed  using  system 
generated  loop  control  variables. 

(5)  An  instance  of  the  loop  control  test,  i.e.  L\,  is  given. 

In  practice  by  taking  the  entire  state  1’  as  the  input  state  from  which  to  achieve 
R  in  step  3,  the  user’s  responsibility  to  express  in  Q  all  properties  needed  in  the 
subgoal  tree  rooted  at  R  is  reduced. 
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9.6.2  COMPUTING  SUCCESSIONS  OF  VALUES 

It  is  assumed  that  the  loop  invariant  Q  characterizes  the  relations  existing  at 
each  iteration  among  values  of  program  variables.  In  particular  all  free  variables  in  R 
and  L  must  be  among  the  free  variables  in  Q.  Therefore  significant  program  variable 
value  changes  are  given  by  comparing  successive  instances  of  Q,  i.e.  Q\  and  Q\'  for  the 
first  iteration.  If  for  eac  argument  position  in  each  relation  in  Q  a  different  program 
variable  is  generated  then  a  correct  computation  rule  for  updating  the  values  in  the 
program  variables  is  a  conditional  assignment  statement  as  described  in  Section  6 
where  each  argument  position  in  Q  has  a  different  w-variable.  That  some  optimization 
(i.e.  reduction  of  the  number  of  program  variables)  could  be  done  at  program 
generation  time  is  suggested  by  two  observations: 

(1)  Many  of  the  values  in  corresponding  argument  positions  in  Q\  and  Q\’  will 
not  change,  i.e.  they  are  constant  for  the  loop, 

(2)  Many  of  those  that  do  change  may  be  controlled  using  the  same  program 
variable. 

Since  the  frame  language  allows  functional  terms  some  successive  values  may  be 
of  the  form,  S|  goes  to  f (s j ).  In  this  case  direct  functional  assignments  of  the  form,  Y| 
may  be  efficiently  placed  at  the  top  of  the  loop  to  avoid  repeated  computation. 
These  ideas  have  led  to  a  number  of  optimization  heuristics  which  are  intended  to 
either: 

(1)  reduce  the  number  of  generated  program  variables, 

or  (2)  recognize  successive  values  related  by  a  function  and  assemble  direct 
functional  assignments, 

or  (3)  reduce  the  portion  of  Q  required  in  a  conditional  assignment. 

by  comparing  respective  argument  positions  in  Q\  and  QV  the  system 
recognizes  two  kinds  of  computation  rules  relating  successive  values,  namely  functional 
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computation,  e.g.  t,  -  f(s,),  and  Boolean  expressions,  e.g.  T(s,,tt),  where  TcQ.  The 

o  stru  ts  a  list  of  significant  change  pairs  each  corresponding  to  one  of  the 
following  cases: 

(1)  s,  and  t,  are  symbollic  expressions  related  by  the  formula  TcQ  and  are 
represented  by  ((s,,  t()T). 

(2)  s,  and  t,  are  symbollic  expressions  related  by  a  function  f  which  is  evaluated 
(using  either  EV  or  EVN),  i.e.  t,  -  f(s,)  and  are  represented  by  <s„  t„  f(st).  Note 
that  in  this  case  it  is  not  sufficient  to  search  terms  in  Q  or  R  to  find  the  function 
f.  During  the  generation  of  p(R)  the  subgoal  tree  rooted  at  R  is  traced  to  return 
the  function  f,  if  any,  used  to  compute  a  succession  of  values  in  the  'oop. 

(3)  s,  and  t,  are  symbollic  expressions  related  by  a  function  f  which  is  not 
evaluated  but  loft  in  symbolic  form,  and  are  represented  by  <s„  f(S|),  f(s,)). 
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9.6  3  ASSEMBLY  OF  PROGRAM  SEGMENTS 

Given  the  inputs  specified  in  Section  9.6.1  and  the  change  list  described  in 
Section  9.6.2,  the  loop  assembly  procedure  does  the  following: 

1.  Generates  a  pair  <Y|,  2,>  of  control  variables  to  take  on  the  successions  of 
values  during  loop  execution  for  each  change  pair  This  is  to  cover  the  case  in 
which  both  S|  and  t|  occur  in  p(R)  and  we  want  to  avoid  the  complexity  of 
considering  statement  order  in  p(R). 

2.  Constructs  assignment  statements  that  initialize  the  control  variables  prior  to 
look.'  entry,  their  values  for  e^'h  execution  of  the  loop  so  that  an  instance  of  the 
loop  invariant  will  be  true  each  time  the  loop  body  is  entered, 

3.  Substitutes  control  variabbles  for  their  values  in  the  loop  body 

4  Aosembles  these  proram  segments  together  to  form  a  "while"  loop. 

The  detailed  loop  assembly  procedure  will  now  be  given.  The  change  pairs  are 
given  on  a  list  CL  and  will  either  be  of  the  form  ((wC,/?)T)  or 

(1)  Set  PA  to  the  first  change  pair  on  the  change  list  CL.  If  all  change  pairs  have  beer 
processed  then  go  to  (8). 

(2)  Generate  a  new  pair  of  variables  Y  and  Z  to  be  used  for  predecessor  and 
successor  values  respectively. 

(3)  Add  (Y  ♦-  e>c)  and  (Y  «-  Z)  at  the  ends  of  p(P)  and  p(R)  respectively. 

Justification:  The  assignment  (Y  <-  u)  is  an  initialization  of  the  variable  Y  to  the  initial 
value  ©c  and  is  done  after  the  basis  program  p(P)  prior  to  loop  entry.  The  assignemtn 
(Y  ♦-  Z)  updates  the  variable  Y  after  the  iteration  program  IP  with  the  successor  of  its 
former  value  which  It  is  anticipated  will  be  in  Z  in  preparation  for  the  next  execution 
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dd  the  replacement  pair  (ex',  Y)  to  the  predececsor  replacement  list  ALP  and  (ft}  Z) 
to  the  successor  replacement  list  ALS  for  later  substitution. 

the  .hange  pair  PA  utilizes  a  function  then  add  the  assignment  (Z  «-  F)  to  the 

successor  function  assignment  list  SASG,  remove  the  first  change  pair  from  CL,  and  go 
to  (1). 

Justification:  The  function  F  is  a  fully  instantiated  function  whose  value  is  equivalent  to 
d.  This  step  causes  Z  to  get  the  successor  value  as  required  in  step  (3). 

(6)  Generate  a  new  variable  W  to  be  used  as  a  call  by  reference  variable  in  a 
conditional  assignment  statement  and  substitute  W  for  all  occurences  of  ft  in  T. 
Justification:  W  will  hold  the  successor  value  for  the  conditional  assignment  to  Z. 

(7)  Add  the  conditional  assignment  (IF  T  THEN  Z  -  W)  to  the  conditional  assignment  list 
SASGR,  remove  the  first  change  pair  from  CL  and  go  to  (1). 

Justification:  The  relation  T  is  assumed  to  specify  the  ordering  between  successive 

values  that  will  be  taken  on  by  the  control  variables  Y  and  Z,  i.e.  using  T  the  successor 

of  Y  may  be  deduced.  This  of  course  implies  the  computability  of  T  as  a  procedure  call 
at  execution  time. 

M  Substitute  variables  ter  values  in  SASG  and  SASGR  using  the  closure  of  ALP. 

Jus.it, cation:  By  closing  the  association  lists  under  substitution  dependence  upon  the 
order  of  substitution  into  SASG  and  SASGR  is  avo.ded.  Subsitution  into  successor 
assignments  only  for  predecessor  values  using  their  associated  variables  (Vs)  is 
sufficient  and  in  fact  required  because: 

M  Any  successor  value  that  may  have  occurred  in  a  relation  T  has  already  been 
substituted  for  by  W. 

(b)  A  successor  value  is  by  our  conventions  the  new  value  that  is  computed  as  a 
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esult  of  executing  the  loop  body  and  occurs  as  an  argument  in  the  invariant  Q  .  By 
generating  a  distinct  pair  of  control  variables  for  each  change  pair,  we  separate 
the  successor  assignments  so  that  each  is  a  function  of  predecessor  values  only. 
Since  the  successor  value  of  one  change  pair  may  be  the  predecessor  of  another 
this  restriction  is  necessary. 

(9)  Substitute  variables  for  values  in  p(R)  and  L  using  the  closure  of  ALP  annd  ALS. 

(10)  Assemble  a  "while"  loop  in  the  following  form: 

P(P); 

SASGRj 
while  ->  L  do 
begin 
SASG; 

P(R); 

SASGR; 

end 

Remark:  Ambiguities  may  arise  because  of  equalities  among  elements  in  the  change  of 
values  list,  i.e.  ((s*,  ti) ...  (sk,  t*)).  There  are  thee  cases,  i.e. 

(a)  Vi,j  [i><j  a  S|^S|]  A  ji,j[iHj  a  t(-t,l 
'•bf  Vi,j  [Mj  a  1 1 Ht | j  a  3i,j[Mj  a  Sj=S|], 

(c)  Vi,j  [,Vj  A  S|^S|  A  t|^t|]  A  3i,j[Mj  A  S| "t |J. 

These  are  resolved  by  referencing  a  trace  of  variable  bindings  in  the  subgoal 
tree  associated  with  each  cccurence  of  each  value  or  by  simply  re-achieving  the 
iteration  step  condition  R  from  state  I"  until  the  ambiguities  disappear. 

To  illustrate  the  process  of  computing  a  succession  of  values  generating 
successor  assignments  end  substituting  into  them  consider  two  examples  from  framos 
treated  aarlier. 

Consider  a  slight  variant  of  the  iterative  rule  TUP  in  figure  12  and  we  have, 

QX  -  0N(M,B1,U)  a  STACKED(B2,B1,U)  a  SMAILER(B2,B1),  and 
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Q\  -  OWM.B2,U>  a  STACKED(B3,B2,U)  a  SMALLER(B3,B2) 
which  results  in  a  change  pair  of  the  form, 

((B1.B2)  STACKED(B2,B1,U)  a  SMALLER(B2,B1)). 
and  the  successor  assignment,  (after  substitution  using  ALP) 

IF  STACKED(Wj  V1  U)aSMALLER(W1  Yl)  then 
21  4-  wi; 

As  another  example  the  iterative  rule  TF ACT  in  figure  10  yields,  (where  we 
assume  here  that  PROD  is  a  primitive  multiplication  function) 

Q\  -  C(X0,1)  a  C(X1,0)  a  FACTO, 0),  and 

QV  -  C(X0,(PR0D  KADOl  0)))  a  C(X1,(ADD1  0)>  A  FACT  ((PROD  1  (ADD1  0)),  (ADD1 

0», 

which  resuits  in  the  change  pairs, 

<0,(AD01  0),  (AUDI  0))  and  (1,(PROO  KADD  0)),(Pk0D  KADD1  0))) 
and  successor  assignments,  (after  subst, lotion  from  closure  of  ALP  and  syntactic 
transformation  from  prefix  functions  as  specified  in  the  frame) 

VI  <-(Vi  .  1), 

V2  «-  (Y2  *  Yl); 

After  the  loop  has  been  assembled,  control  is  given  to  an  update  procedure 
which  applies  the  rule  of  invariance  using  the  given  output  assertion  S  as  previously 
described.  If  no  output  assertion  is  given  then  the  loop  is  interpret, vely  executed  until 
the  goal  G  is  true.  This  is  required  to  provide  a  correct  initial  state  for  continued 


program  generation. 
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9.7  STRUCTURED  PROGRAMMING 

The  objective  of  structured  programming  is  to  provide  mental  and  orgamza.ional 
tools  by  which  the  programmer  may  create  large  systems  while  Keeping  the  problem 
complexity  firmly  within  his  mental  grasp  at  each  step  of  the  creation.  In  Section  /  the 
current  rather  rudimentary  features  in  the  system  were  briefly  described  a  ,j  an 
example  given. 

Structured  programming  consists  of  constructing  a  program  to  solve  a  particular 
problem  by  specifying  a  sequence  of  operations  in  which  the  operations  are  not 
necessarily  "primitive"  to  the  interpreter,  e.g.  computer,  human,  etc.,  but  if  successfully 
carried  our  will  correctly  solve  the  proDlem.  For  each  operation  in  the  sequence  th.  ♦ 
is  not  primitive  i.e.  the  procedure  is  declared  to  be  an  assumption,  the  function  it 
performs  becomes  a  subproblem  <p,I,G>  for  the  system  that  may  be  similarly  expanded 
into  a  sequence  of  perhaps  again  non-primitive  operations.  The  process  continues  by 
step-wise  refining  each  operation  until  the  problem  can  be  solved  correctly  using  only 
"primitive"  operations.  The  relationship  between  higher  level  operations  and  the 
equivalent  sequences  of  sub-operations  that  may  be  generated  by  successive  levels  of 
structured  development  take  the  form  of  a  tree  with  the  initial  generated  program  at 
the  root. 

During  the  structured  development  process  an  overall  structure  for  the  program 
is  built  up  that  primitive  constructs  will  have  to  fit  into.  An  implicit  system  assumption 
is  that  a  lower  level  operation  will  not  have  side  effects  that  affect  the  correctness  of 
the  overal  structure  containing  it.  This  is  essentially  a  "top-down"  process,  i.e.,  one 
proceeding  from  the  general  functional  description  level  down  to  specification  of 
primitives.  However,  there  is  a  "bottom-up"  component  that  occurs  when  on  the  basis 
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of  information  gained  while  generating  lower  level  primitives,  or  to  satisfy  the 
requirements  of  using  them,  the  overall  structure,  i.e.,  operations  previously  generated 
at  a  higherfdoser  to  the  root)  level,  must  be  modified.  This  may  result  in  backtracking 
if  these  modifications  invalidate  any  previously  specified  operation.  Also  the  over  Vl 
structure  may  be  modified  by  shifting  a  high  level  operation  specification  to  one  which 
utilizes  more  mathematical  properties  of  the  problem  domain.  In  the  current  system 
any  bottom-up  component  and  shiftsfmodif, cations)  to  higher  level  operations  are  do„o 
interactively  by  using  the  advice  system.  A  useful  automation  of  structured 
programming  should  provide  more  powerful  control  and  record  keeping  facilities  fo 
the  traversing  the  structured  development  tree. 

The  growing  popularity  of  structured  programming  and  its  apparent  usefulness 
for  software  understandability  tand  therefore  reliability)  indicates  the  need  for 
continued  resoarcn  to  automate  this  process.  Certainly  it  is  possible  now  to  build  an 
interactive  structured  programming  system  that  can  handle  the  top-down  expansion, 

bottom-up  backtracking  and  shifts  at  any  level  for  the  augmentation  of  the 
programmer. 
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1.  A  Simple  Translator  from  Infix  to  Polish  Notation 

This  example  illustrates  the  generation  of  conditional  tranches  within  'oops  in  a 
program  to  convert  strings  of  symbols  in  infix  form  into  strings  in  polish  forrr  i.e. 
"(X.Y.Zr  converts  to  "XY+2*".  This  is  e  common  symbol  manipulate  less  m  a 

compiler.  The  example  shows  how  the  system  can  be  used  to  program  in  a  structured 
"top  down"  manner. 

A  fully  parenthesized,  syntactically  correct  infix  expression  of  a  specified  lengtn 
is  given  as  input  and  on  output  a  result  stack  S  contains  the  Polish  string.  A  working 
stack  R  is  used  during  the  translation.  We  may  consider  the  basic  data  structures 
(stacks), .e.  variables,  constructors, (e.g.  push)  and  selectors  (e.g.  pop)), and  the  primitive 
operators  as  given.  Then, in  this  case, the  user  proceeded  in  the  following  steps. 

(1)  First  the  actions  of  the  top  level  of  the  program  were  described  by  declarative 
statements  (i.e.  the  definitions  of  RECOGNIZED  and  PROCESSYM  in  terms  of  basic 
concepts  such  as  "X  is  a  left  parenthesis",  and  intermediate  concepts  such  as  "pop 
operators  from  stack  X  and  push  them  onto  stack  Y". 

(2)  Then  at  the  second  level,  Rules  -  in  this  case  iterative  rules  -  were  given  tor 
writing  loops  that  implement  the  intermediate  concepts.  In  doing  this, the  user  specified 
the  major  characteristics  of  a  loop  and  left  the  system  with  the  details  or  deciding 
whether  to  write  such  a  loop, and  if  so,  with  the  choice  of  local  variables, the  actual 
operations  in  the  loop  body  and  their  order, (in  so  far  as  that  was  not  specified  )  and 
with  looking  after  the  updating  of  the  local  variables.  Thus  in  order  to  write  the  top 
level  loop,  TSLOOP,  to  achieve  POLTSKT.U.V),  the  user  must  have  "thought  out"  an 
invariant  relation  between  the  elements  manipulated  by  the  loop  body  and  what  the 
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eoals  of  .he  loco  body  were  (in  this  case  one  of  the  goals  i,  a  fop  level  concept, 

RECOGl\WtCKX,Y,Z;-).  The  system,  it  it  uses  this  role  in  construct, ng  the  output,  will 

construct  a  loop  body  including  update  assignments,  and  assemble  it  into  a  WHILE 

statement.  Sunilary,  in  this  example  the  user  has  supplied  ilerative  rules  tor  POPOPS 
anr4  POPHOPS. 

The  output  program  consists  c‘  a  main  program,  i.e.  PR0C1,  containing  a 
compound  conditional  statement  which  splits  up  the  cases  tor  processing  as  a  , unction 
°t  the  input  symbol.  Each  allowable  input  symbol  must  be  either  o.  type  variable, 

el*  ParentheS'Sl  0r  r'3hl  Parenthesis  The  main  program  proceses  the  case 
in  which  the  input  symbol  is  an  operator  and  generates  calls  to  contingency  programs, 

PR0C3,  PHOC4,  6  PH0C3,  to  be  generated  for  the  other  three  alternatives.  The 
procedure  calls  PKOC2,  PW)C6,  <4  result  in  error  exits. 

The  various  parts  of  the  Frame  definition  win  be  given  below  foilowod  by  the 
generated  programs. 
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RELATIONS  USED  IN  THE  FRAME  DEFINITION: 


RELATION 

INTERPRETATION 

FLUENT 

PARTIAL 

UNIQUENESS 

C(X,Y) 

"Contents  of  X  is  Y" 

TRUE 

FALSE 

C(X,*) 

INTEGER(X) 

"X  is  an  inteper" 

TRUE 

FALSE 

FALSE 

VAR(X) 

"X  is  a  variable" 

FALSE 

TRUE 

false 

LP(X) 

X  is  a  left  paren" 

FALSE 

TRUE 

false 

RP(X) 

"X  is  a  right  paren" 

FALSE 

TPUE 

FALSE 

OP(X) 

"X  is  an  operator" 

FALSE 

TRUE 

FALSE 

ISVAR(X) 

"X  is  a  program  var¬ 
iable" 

FALSE 

FALSE 

FALSE 

NEXTSYM<X) 

"A  value  for  X  is 
input" 

TRUE 

false 

FALSE 

RECOGNIZED(X,Y,Z)  "Symbol  X  is  recog¬ 
nised  wrt  stacks  Y  & 

TRUE 

Z“ 

false 

FALSE 

PROCESSYM(X,Y,Z)  "Symbol  X  is  processed  TRUE 
wrt  stacks  Y  &  Z" 

FALSE 

FALSE 

>(X,Y) 

"X  is  greater  than 

Y" 

FALSE 

FALSE 

FALSE 

<(X,Y) 

"X  is  less  than  Y" 

FALSE 

FALSE 

FALSE 

POLISH(X) 

"X  contains  a  Polish 
sequence" 

TRUE 

FALSE 

FALSE 

ROLTSUX.Y.Z) 

Translate  an  infix 
string  x  symbols 
long  to  Polish 
using  stacks 

Y  and  Z" 

TRUE 

FALSE 

FALSE 

“(X,Y) 

"X  is  equal  to  Y" 

FALSE 

FALSE 

FALSE 

RUSHEO(X.Y) 

"X  is  pushed  onto  Y" 

TRUE 

FALSE 

FALSE 

POPHtD(X) 

''X  is  popped" 

TRUE 

FALSE 

FALSE 

TOPPECKX.Y.Z) 

"The  top  symbol  of 

TRUE 

FALSE 

TOPPED<X,Y,*) 
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stack  Y  of  size 
Z  is  assigned  to  X" 


POPOPS(X.Y) 

"Pop  operators  from 

X  and  push  onto  Y" 

TRUE 

FALSE 

FALSE 

POPHOPS(X,Y,Z) 

"Pop  operators  from 

Y  that  have  greater 
priority  than  X  and 
push  onto  Z" 

TRUE 

FALSE 

FALSE 

STACKSIZE(X,Y) 

"Size  of  stack  X  is 

Y" 

TRUE 

FALSE 

STACKSIZE(X,*) 

STACK(X) 

"X  is  a  stack" 

FALSE 

FALSE 

FALSE 

EMPTY(X) 

"Stack  X  is  empty" 

FALSE 

TRUE 

FALSE 

ITERATIVE  RULES: 


NAME:  TSLOOP 

BASIS:  N£WVAR(X,Y)  a  C(X,0) 

INVARIANT:  C(X,W)  a  INTEGER(W)  a  STACK(V)  a  STACK(U)  a  ISVAR(Y) 

ITERATION  STFP:  C(X,(AD01  W»  a  NEXTSYM(Y)  a  RECOGNIZED{Y,U,V) 

CONTROL  TEST:  >(X,T) 

OUTPUT  ASSERTION:  POLISH(V) 

GOAL:  P0LT$L(T,U,V) 


NAME:  RLOOP 

BASIS:  NtWVAR(X)  a  STACKSIZE(U.Z)  a  TOPP£D(X,U,Z) 

INVARIANT:  C(X,Y)  a  =(Y,(T0P  U))  a  STACK(U)  a  STACK(V)  a  STACKSIZE(U,W) 

ITERATION  STEP:  PU3HED<X,V)  a  POPPED(U)  a  TOPPELKX,U,W) 

CONTROL  TEST:  -OP(X) 

OUTPUT  ASSERTION:  POFOPSfU.V) 

GOAL:  POPCPS(U,V) 


NAME: 

BASIS: 

INVARIANT: 
ITERATION  STEP: 
CONTROL  TEST: 
OUTPUT  ASSERTION: 
GOAL: 


0L00P 

NEWVAR(X)  a  STACKSIZE(UJ)  A  TOPP£D(X,U,T) 

C(X,Y)  a  *={Y,(T0P  U))  a  STACK(U)  A  STACK(V)  A  STACKSIZE(U,W) 
PUSHED(X.V)  A  POPPED(U)  A  TOPPED(X,U,W) 

OP(X)  v  <((PRI0RITY  XXPRI0R1TY  Z)) 

POpHOPS(Z,U,V; 

POPHOPS(Z,U,V) 
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PRIMITIVE  PROCEDURE 

PRE-CONDITIONS 

POST-CONDITIONS 

P'Jsh(X.Y) 

"Push  symbol  X 
onto  stack  Y" 

ISVAR(X)  a  STACK(Y) 
a  STACKSIZE(Y,Z) 

PUSHED(X.Y) 

a  STACKSIZE(X,(SUB1  Y)) 

pop(X) 

"Pop  stack  X" 

STACK(X)  a  STACKSIZE(X,Y) 

A  -EMPTY(X) 

POPPED(X) 

a  STACKSIZE(X,(SUB1  Y)) 

getnext(X) 

"Get  next  symbol" 

ISVAR(X) 

NEXTSYM(X) 

♦*(X,Y) 

"Assign  Y  to  X" 

ISVAR(X) 

C(X,Y) 

top(X.Y) 

"Put  top  of  stack 

Y  in  X" 

ISVAR(X)  a  STACK(Y) 
a  STACKSIZE(Y.Z) 

TOPPED(X,Y,Z) 
a  C(X,(TOP  Y)) 

DEFINITIONS: 

BODY  OF  DEFINITION 

RELATION  DEFINED 

(VAR(X)  v  LP(X)  v  RP(X)  v  OP(X))  a  PROCESSYM{X,Y,Z) 

RECOGNIZEDtX.Y.Z) 

VAR(X)  a  PUSHED(X.Z) 

PROCESSYM(X,Y,Z) 

LP(X)  a  PUSHEDfX.Y) 

PROCESSYM(X,Y,Z) 

RP(X)  a  POPOPS(Y.Z)  a  POPPED<X) 

PROCESSYM(X,Y,Z) 

OP(X)  a  POPHOPS(X,Y,Z)  a  PUSHED(X.Y) 

PROCESSYM(X,Y,Z) 

-(X,0)  v  1NTEGER((SUB1  X)) 

INTEGER(X) 

INITIAL  STATE: 

STACKS'  a  STACK(R)  a  STACKSIZE(S,I)  a  STACKSIZE(R,J) 
ALGEBRAIC  SIMPLIFICATION:  (SUB1(ADD1  X))  -♦  X 
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PR0C1  <N  R  S) 

ISVAR(X  1  );ISVAR(X2);ISVAR(X3);STACK(S);STACK(R); 

COMMENT 

INPUT  :C0NDIT10NS: 

STACi<SIZE(R  J)aSTACKSIZE(S  I) 

OUTPUT  :CONDITIONS: 

POLISH(S); 

COMMENT 

PROC6  ATTEMPTS:TO:ACHIEVE:  {POPPED  R} 

PROC5  ATTEMPTS:TO:ACHIEVE:  (PKOCES3YM  X2  R  3) 
PROC4  ATT£MPTS:TO:ACHIEVE:  (PR0CES3YM  X2  R  S) 
PROC3  ATT EMPTS:TO:ACHIEVE:  (PROCESSYM  X2  R  S) 
PROC2  ATTEMPTS.  TO:ACHIEV£:  (PROCESSYM  X2  R  S) ; 
BEGIN 
XI  4-  O; 

WHILE  ->(X1  N)  DO 
BEGIN 

Z1  -  (X 1  + 1 ); 

GETNEXT(X2); 

IF  -0P(X2)  THEN 
IF  ->kP(X2)  THEN 
IF  -VAR(X2)  THEN 
IF  -•LP(X2)  ThEN 
PR0C2(X2  R  S) 

ELSE  PR0C3(X2  R  S) 

ELSE  PkOC4(X2  R  S) 

ElSE  PR0C5{X2  R  S) 

ELSE 
BEGIN 
T0P(X3  R); 

WHILE  0P(X3)  a  ^({PRIORITY  X3XPRIORITYX2))  DO 
BEGIN 
PU3H(X3  C) 

IF  EMPTY(R)  THEN 
PROCC(R) 

ELSE 

BcGIN 

POP(R); 

END 

T0P(X3  R)j 
END 

PU5H(X2  R)j 
END 

XI  <-  Z1 
END 
END 


PR0C3  (X2  R  S) 

ISVAR(X2)iSTACK{R); 

COMMENT 
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INPUT  :CONDITIONS: 

STACKSIZE(R  I) 

OUTPUT  :CONDITIONS : 

STACK$IZE(R  (ADD1  I))aPUSHED(X2  Rh 
BEGIN 
PUSH(X2  R)j 
END 

PROC4  (X2  R  S) 

ISVAR<X2);STACK(S)i 

COMMENT 

INPUT  :CONDITIONS: 

STACKSIZE(S  I) 

OUTPUT  .'CONDITIONS: 

STACKSIZE(S  (ADD1  I))aPUSHED(X2  S); 
BEGIN 
PUSH(X2  S): 

END 

PROC5  <X2  R  S) 
ISVAR(X4);STACK(S);STACK(R); 

COMMENT 
INPUT  :CONDITIONS: 

STACKSIZEIR  J)aSTACKSIZE(S  I) 

OUTPUT  :CONDITIONS: 

POPOPS(R  S); 

COMMENT 

PROC7  ATTEMPTS:TO:ACHIEVE:  (POPPED  R) ; 
BEGIN 
TOP(X4  R); 

WHILE  OP(X4)  DO 
BEGIN 
PU3H(X4  S) 

IF  EMPTY(R)  THEN 
PROC7(R) 

ELSE 

BEGIN 

POP(R); 

END 

T0P(X4  R)j 
END 

IF  EMPTY(R)  THEN 
PR0C8(R) 

ELSE 

BEGIN 

POP(Rh 

END 

END 


130 


APPENDIX  A 


2.  Integer  Square  Root  Problem 

As  an  example  of  generating  a  program  for  numerical  computation  consider  the 
task  of  computing  the  largest  integer  k  for  a  given  n  such  that  k  is  less  than  or  equal 
to  the  square  root  of  n.  An  essential  fact  formalied  in  the  Frame  definition  is  that  the 
difference  between  the  itn  and  (i+l)st  squares  is  2i+l,  i.e. 

(I+l)3  -  i3  -  i2  +  2i  +  1  -  r3  -  2i  +  1  -  i  +  i  +  1. 

This  allows  the  simple  iterative  upward  computation  for  any  i,  using  two 
variables  Y1  and  Y2  and  only  the  arithmetic  operation  of  addition,  of  i  in  Y1  and  (i+l)2 
in  Y2  such  that  when  the  value  in  Y2  exceeds  n  then  Y1  will  have  the  desired  value  k. 

The  Frame  definition  in  addition  to  a  primitive  procedure  for  assignment  is  given 
below  followed  by  the  generated  program. 
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RELATION 

INTERPRETATION 

FLUENT 

PARTIAL 

UNIQUENESS 

C(X,Y) 

"Contents  of  X  is  YH 

TRUE 

FALSE 

C(X,<) 

>(X,Y) 

"X  is  greater  than  Y" 

FALSE 

FALSE 

FALSE 

ISQRT(X.Y) 

"X  contains  the 
integer  square 
root  of  "Y" 

TRUE 

FALSE 

ISQRT(X,*) 

VSQ(X.Y) 

"X  equals  Y  " 

TRUE 

FALSE 

FALSE 

ISVAR(X) 

"X  is  a  variable" 

FALSE 

FALSE 

FALSE 

ITERATIVE  RULE: 


NAME: 

BASIS: 

INVARIANT: 
ITERATION  STEP: 
CONTROL  TEST: 
OUTPUT  ASSERTION: 
GOAL: 


TSQ 

NEWVAR(X)  a  C(X,(ADD1  0))  a  C(W,0) 

C(W,Y)  A  C(X,Z)  a  VSQ(Z,(ADD1  Y)) 

C(W,(ADD1  Y))  a  C(X,(PLUS  Z(ADD1(PLUS(ADD1  Y)(ADD1  Y))))) 
><Z,V) 

ISQRT(W,V) 

ISQRT(W.V) 


AXIOMS: 

VSQUADD1  O),(AD01  0)) 

VSQ((MINUS  Z(ADOi(PLUS  Y  Y))),(SUB1  Y))  c  V SCXZ.Y) 
INITIAL  STATE: 

ISAVR(XO) 

ALGEBRAIC  SIMPLIFICATION: 

(SUBKADD1  X))  -+  X 
(MINUS  (PLUS  X  Y)Y)  -♦  X 
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PROCKXO  N) 
ISAVR(XO); 

COMMENT 
INPUT  ASSERTION: 
NONE 

OUTPUT  ASSERTION: 
ISQRT(XO.N); 

BEGIN 
XO  «-  0; 

Y2  *-  (0+1); 

WHILE  ->  (Y2,N)  DO 
BEGIN 

XO  -  (XO  ♦  1); 
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3.  Hand-Eye  Tasks 

In  a  simple  robotics  environment  an  "eye"  (usually  a  Vidicon  TV  camera)  may  be 
used  to  locate  objects  on  a  table  and  a  computer  contolled  arm  carries  out 
manipulatory  tasks  with  these  objects.  We  assume  the  identity  and  location  of  the 
objects  in  the  scene  have  been  discovered  and  are  given  in  the  initial  state. 

Programs  written  for  autonomous  robot  control  must  be  capable  of  on  carrying 
some  sort  of  dialogue  with  the  real  world  since  most  relations  will  be  partial  and  the 
outcome  of  operations  will  not  be  totally  reliable.  Conditional  calls  to  contingency 
procedures  is  one  way  of  establishing  this  dialogue. 

The  frame  oeTinition  is  given  below  followed  by  a  generated  program. 
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rel axioms  used  in  the  frame  definition: 


RELATION 

INTERPRETATION 

FLUENT 

RaRtial 

UNlQUENEs 

AT(X,Y) 

MASIX.Y) 

(  w*'  Krwxyj) 

"X  is  at  location  YH 
*X  has  Y" 

"X  can  ronEh 
from  Y  to  2" 

TRUE 

TRUE 

true 

FALSE 

PALBe 

!fR(JE 

AT(X,*) 

;paise 

fPALSE 

COLL  IDLCKA,Y,2)"X  collided 

true 

^PALSE 

false 

bdtwooh  Y  and  2" 

DR0F»f»£0(W,k,Y(2) 

"W  dropped  X 
botwoon  Y  and  Z* 

TRUE 

false 

false 

AVAILABLE^, Y) 

"X  is  ovailablfc 
flt  Y" 

TRUE 

TRUE 

FALSE 

MIS3ED(K,Y,2) 

"X  mlsood  Y 
at  2" 

true 

false 

FALSE 

ROBOT(K) 

is  a  robot" 

false 

FALSE 

FALSE 

PRIMITIVE  PROCEDURE 


re  kHA  IXltLZ) 
"A1  reaches 
from  LI  TO  L2" 


PRE-CONDITIONS 


PdST-CON&lVfdNS 


ROSOT(AL)  a08J<01)  a  HAS(Al,^l!)  fAT<6l,L-£)  A'XYtAT'L^) 
a  -  HA9(A1,02)  a  OANRPAOW(A  1 .1 1  jig) 


tr*nsporKAl,OUU2) 
"A1  transports  01 
from  LI  to  L2* 

pickup(A  1,0 14.1) 

"A  I  picks  up  01 
at  LI" 


R000T<Al)  a  03J(01)  A  WV&Al.Ol) 
a  ATvOUD  aaT<AU4) 
a  CA\REACKA1,U,L2) 

KOOOr<Al)  A  O&Wl)  A  AWI.U) 

A  -  t4A5s\Al,02>  A  AVkAtfLEWUl) 
a  AT\Al,ll) 


|AT<0T;L2)  A  AT<Al,l2» 

«  ^OOuiDEtXAl ,1^,12) 
A^^iXAliOl.ll.l^)} 

HA%<Al,M)  *  VfiSStO* A  1,01,11) 


putdownf A  1,01,L1)  R0Q0T1A1)  A  MA$<Al,0l) 

A1  puts  down  01  aATtAI.U) 

at  Ll" 


INITIAL  STATE: 

ROBOT(ARM)  a  OBJtBlKl)  a  AT(BIK1,P)  a  AT(AWM,B) 
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PR0CKBLK1  ARM  P  S) 

ROBOT(ARM);  OBJ(BLKl); 

COMMENT 

INPUT:CONDITIONS: 

AT(BLK1  P)  a  AVAILABLE(BLK1  P)  a  CANREACH(ARM  S  P) 
a  CANREACH(ARM  P  S) 

OUTPUT-.CONDITIONS: 

HAS(ARM  BLK1)  a  AT(ARM  S)  a  AT(BLK1  S); 

BEGIN 

IF  -  AVAILABLE(BLK1  P)  THEN 
PROC2(ARM  BLK1) 

ELSE 

BEGIN 

IF  -  CANREACH(ARM  S  P)  THEN 
PROC3(ARM  P) 

ELSE 

BEGIN 

REACH(ARM  S  P)j 
IF  -  AT(ARM  P)  THEN 

IF  i  AT(ARM  P)  a  COLLIDED<ARM  S  P)  THEN 
PROC4(ARM  P) 

ELSE  PROC5(ARM  P) 

END 

PICKUP(ARM  BLK1P) 

IF  -  HAS(ARM  BLK1)  THEN 

IF  HAS(ARM  BLK1)  a  MISSED(ARM  BLK1  P)  THEN 
PROC6(ARM  BLK1) 

ELSE  PROC7(ARM  BLK1) 

END 

IF  -  CANREACH(ARM  P  S)  THEN 
PROC10(BLKI  S) 

ELSE 

BEGIN 

TRANS PORT(ARM  BLK1  P  S); 

IF  -  AT(BLK1  S)  THEN 

IF  AT(BLK1  S)  A  DROPPED<ARM  BLK1  P  S)  THEN 
PROC1 1(BLK1  S) 

ELSE  PROC12(BLKl  S) 

ENO 

END 
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A.  n-Queen?  Puzzle 

To  illustrate  how  the  program  generation  system  may  be  used  to  solve  puzzles, 
a  backtrack  problem  solving  algorithm  (see  Section  9.1)  is  axiomatized  in  the  frame 
definition  language  to  solve  the  n-Queens  puzzle.  The  object  of  this  puzzle  is  to  place 
n  queens  on  an  n  x  n  chessboard  such  that  they  are  mutually  non-attacking,  the 
algorithm  proceeds  by  placing  queens  on  the  board  a  column  at  a  time,  backing  up 
when  no  placement  is  possible. 

The  frame  definition  for  this  problem  is  given  below  followed  by  a  generated 
solution  programs  for  the  4-Queens  and  8-Queens  cases. 
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RELATIONS  USED  IN  THE  FRAME  DEFINITION: 


RELATION 

INTERPRETATION 

FLUENT 

PARTIAL 

UNIQUENESS 

SAFE(X.Y) 

"Square  X,Y  is  safe" 

TRUE 

FALSE 

FALSE 

bOTHSAF£(W,X,Y,Z) "Square  W,X  is  safe 

TRUE 

FALSE 

FALSE 

wrt  square  Y,Z" 

ALLSAFE(X,Y,Z) 

"Square  X,Y  is  safe 

TRUE 

FALSE 

FALSE 

wrt  columns  1,„,Z" 

QUEEN(X.Y) 

"A  queen  is  on 

TRUE 

FALSE 

FALSE 

Square  X,Y" 

QPLACED(X,Y,Z) 

"Queens  are  placed 

TRUE 

FALSE 

FALSE 

in  columns  XM.,Z" 

=(X,Y) 

"X  is  equal  to  Y" 

FALSE 

FALSE 

FALSE 

PLACED(X) 

"X  queens  have 

TRUE 

FALSE 

FALSE 

been  placed" 

PRIMITIVE  PROCEDURE  PRE-CONDITION  POST-CONDITION 

placequeen(I,J)  SAFE(I.J)  QUEEN(I,J) 

"Place  queen  on  square  I,J" 


AXIOMS: 

ANTECEDENT  CONSEQUENT 


«(J,1)  v  a  ALLS AFE(I,J,J)}  SAFE(I.J) 

=(K,1)  v  {REQUEST(QUEEN(IP,(EVN(SUB1  K))))  ALLSAFE(I,J  K 

a  BOTHS AFE( I,J,IP<(EVN(SUB  1  K)))a  ALLSAFE(U,(EVN(SUB1  K)))} 


—(11,12)  a  ->=((EVN(PLUS  II  J1)),(EVN(PLUS  12  J2))) 

— ((EVN(DIFFERENCE  11  J1)),(EVN(DIFFERENCE  12  J2))) 


BOTHSAFE(ll,Jl,12,J2) 


DEFINITIONS: 


BODY  OF  DEFINITION 


— <I|<EVN(ADD1  N)))  a  ->=(J,0)  a  “(J,(EVN(ADD1  N))) 
v  {QUEEN(I.J)  a  QPLACEDU,(EVN(AD01  J)),N)} 
v  QPLACED«EVN(ADD1  I)),J,N) 

QPLACED(1,1,N) 


RELATION  DEFINED 
QPLACEIXUN) 


PLACEtXN) 


INITIAL  STATE:  (empty) 
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PROCl 

BEGIN 

PLACEQUEEN{2  1) 
PLACEQUE£N<4  2) 
PLACEQUEENU  3) 
PLACEQUEEN<3  4 h 
END 


PROCl 

BEGIN 

PLACEQUEENI2  lh 
PLACEQUEEN(5  2); 
PLACEQUEENI7  3); 
PLACEQUEENd  4); 
PLACEQUEENI3  5); 
PLACEQUEEN{8  6); 
PLACEQUEEN(6  7h 
PLACEQUEEN(4  8); 
END 
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APPENDIX  B  -  AN  INTERACTIVE  SESSION 

A  sample  interactive  session  is  here  presented  to  illustrate  the  system’s  use  in 
frame  definition  and  program  generation.  Statements  typed  by  the  user  will  always  be 
prompted  by  V\  The  top  level  system  function  is  "SUBGOAL"  which  is  called  in  the 
manner  given  below  to  accept  a  frame  definition  from  the  terminal.  Comments  to  aid 


the  reader’s  understanding  of  the  dialogue  will  be  enclosed  in  quotes. 
♦(SUBGOAL) 

"The  system  now  enters  an  interactive  mode  for  Frame  definition." 

*  ♦  ♦  ♦  SEMANTIC  FRAME  DEFINITION  ♦  ♦  ♦  ♦ 

RULE  TYPE*  AXIOM 

RULE  NAME*  AOIMTOP 

IS  THIS  AN  ASSUMPTION?*  NIL 

IS  ThE  RULE  DIRECTLY  RECURSIVE?*  NIL 

INEQUALITIES  IN  ARGUMENT  POSITIONS*  NIL 

PRECONDITIONS: 

*  ROBOT(Xl)  a  ON(Xl,X2)  a  -STACKED(X3,X2); 

POSTCONDITIONS: 

*  ONTOP(Xl); 

RULE  TYPE*  PRIMITIVE  PROCEDURE 
RULE  NAME*  STANDON(Rl.Zl) 

IS  THIS  AN  ASSUMPTION?*  NIL 
IS  THE  RULE  DIRECTLY  RECURSIVE?*  NIL 
INEQUALITIES  IN  ARGUMENT  POSITIONS*  NIL 
PRECONDITIONS: 

*  ROBOT(Rl)  a  -ON<R lfW  1 )  a  BOX(Zl)  a  CLOTHES(Ol)  a  WEARING(R1,01) 
a  AT(Zl.Yl)  a  AT <R  1  ,Y  1 ); 

POSTCONDITIONS: 

*  ON(Rl,Zl)j 

RULE  TYPE*  PRIMITIVE  PROCEDURE 
RULE  NAME*  DRESS(Rl.Ol) 

IS  THIS  AIM  ASSUMPTION’*  T 
IS  THE  RULE  DIRECTLY  RECURSIVE?*  NIL 
INEQUALITIES  IN  ARGUMENT  POSITIONS*  NIL 
PRECONDITIONS: 

*  ROBOT(Rl)  a  CLOTHES(Ol); 

POSTCONDITIONS: 

*  WEARING(R1,01); 

RULE  TYPE*  PRIMITIVE  PROCEDURE 
RULE  NAME*  TRAVEL(R1,L1,L2) 

IS  THIS  AN  ASSUMPTION?*  NIL 

IS  THE  RULE  DIRECTLY  RECURSIVE?*  NIL 
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KS ARajMENT  POS,T'ONS*  <ri"> 

*  AT(R1,L2); 

rule  type*  primitive  procedure 

RULE  NAME*  ST£PUP(X1,Y1,Z1) 

IS  THIS  AN  ASSUMPTION?*  NIL 
|.SJaHE  RULE  DIRECTLY  RECURSIVE?*  NIL 
iS  ARGUMENT  P0SITI«.  <R1,V) 

S ST,XI1  A  STACKEIX21-Y»  *  «w.m 

*  0N(X1,Z1); 

RULE  TYPE*  ITERATIVE 
RULE  NAME*  ITONTOP 

DIRECTLY  RECURSIVE?*  NIL 
BASIS  CONDITION: 

*  ROBOT(Xl)  a  ON(Xl,X2): 

INVARIANT: 

*  ON(Xl,X3)  A  STACKED(X4,X3); 

ITERATION  STEP  CONDITION- 

*  0N(X1,X4); 

CONTROL  TEST*  NIL 
OUTPUT  ASSERTION*  NIL 
GOAL*  ONTOP(X1)j 

RULE  TYPE*  NIL 

INITIAL  STATE: 

SEMANTIC  PROPERTIES  OF  RELATIONS: 

!c  A  FUNCTION  OF  THE  STATE?*  NIL 

IS  ROBOT(Rl)  PARTIAL?*  NIL 

ARGUMENT  UNIQUENESS  PROPERTIES*  NIL 
!e  ?I!?1,L1)  A  FUNCTION  OF  THE  STATE?*  T 

IS  AT(R1, LI)  PARTIAL?*  NIL 
ARGUMENT  UNIQUENESS  PROPERTIES*  (Rl,*) 

IS  STACKED(X4,X3)  A  FUNCTION  O'*  THE  STATE?*  T 
IS  STACKED<X4,X3)  PARTIAL?*  NIL 

argument  uniqueness  properties*  <X4,*) 
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IS  BOX(Zl)  A  FUNCTION  OF  THE  STATE?*  NIL 

IS  BOX(Zl)  PARTIAL?*  NIL 

ARGUMENT  UNIQUENESS  PROPERTIES*  NIL 

IS  ONTOP(Xl)  A  FUNCTION  OF  THE  STATE?*  T 
IS  ONTOP(Xl)  PARTIAL?*  NIL 
ARGUMENT  UNIQUENESS  PROPERTIES*  NIL 

IS  CLOTHES(Ol)  A  FUNCTION  OF  THE  STATE?*  NIL 
IS  CLOTHES(Ol)  PARTIAL?*  NIL 
ARGUMENT  UNIQUENESS  PROPERTIES*  NIL 

IS  WEARING(Rl.Ol)  A  FUNCTION  OF  THE  STATE?*  T 
IS  WEARING(Rl.Ol)  PARTIAL?*  NIL 
ARGUMENT  UNIQUENESS  PROPERTIES*  NIL 

IS  0N(X1,Z1)  A  FUNCTION  OF  THE  STATE?*  T 
IS  0N(X1,Z1)  PARTIAL?*  NIL 
ARGUMENT  UNIQUENESS  PROPERTIES*  (XI,*) 

FILENAME*  DSK:PCLI 
TRACE  MODE?*  T 
PERFORMANCE  STATISTICS?*  T 
LOOKAHEAD?*  NIL 
ALGEBRAIC  SIMPLIFICATION?*  NIL 

SUBGOALING  SYSTEM  GENERATED!!! 

A  subgoalmg  system  corresponding  to  the  Frame  has  now  been  generated 
and  the  system  may  now  receive  a  goal  to  achieve." 

: 

SUBMIT  GOAL*  ONTOP(M) 

UO  YOU  WaNT  THE  PROGRAM  LIBR  <RY?*  NIL 
DO  YOU  HAVE  ANY  ADVICE?*  T 
***  ENTERING  ADVICE  SYSEM  *** 

|«l*  TRY  STANDON  BEFORE  STEPUP 

<*2*  NIL  "Exit  advice  system  and  begin  program  generation." 

RULES  ENTEREO  AND  GOALS  PENDING  IN  CURRENT  SUBGOAL  TREE  PATH: 
— ITONTOP 


RULES  ENTERED  AND  GOALS  PENDING  IN  CURRENT  SUBGOAL  TREE  PATH: 
— (ITONTOP(ON  M  X2))STANDON 

RULES  ENTERED  AND  GOALS  PENDING  IN  CURRENT  SUBGOAL  TREE  PATH: 
— (ITONTOP(ON  M  X 2 ))( ST ANDON( WEARING  M  SHOES))DRESS 

((DRESS  M  SHOES;; 

"Current  program  segment  generated  is  displayed  in  this  form." 

RULES  ENTERED  AND  GOALS  PENDING  IN  CURRENT  SUBGOAL  TREE  PATH: 


— <ITONTOP(ON  M  X2)XSTAND0N(AT  M  L))TRAVEL 

((DRESS  M  SHOESXTRAVEL  M  CORNER  L» 

((CRESS  M  SHOESXTRAVEL  M  CORNER  LXSTANDON  M  Bl) 
"This  cons'.tutes  the  basis  program  for  the  iterative  rule." 


RULES  ENTERED  AND  GOALS  PENDING  IN  CURRENT  SUBGOAL  TREE  PATH: 
— (ITONTOP(ON  M  B2))STANDON 

STANDON  IS  FAILING!!! 

—(■’ON  M  Wl)  WAS  THE  LOSER 

"STANDON  is  only  applicable  for  climbing  from  ground  level." 

RULES  ENTERED  AND  GOALS  PENDING  IN  CURRENT  SUBGOAL  TREE  PATH: 
— (ITONTOP(ON  M  B2))STEPUP 

((STEP  M  Bl  B2)) 

"This  is  part  of  the  loop  body." 


RULES  ENTERED  ANr  GOALS  PENDING  IN  CURRENT  SUBGOAL  TREE  PATH: 
— (ITONTOP(ONTOP  M))AONTOP 

"The  system  now  interpretively  updates  the  state  until  the  goal  Is 
true,  then  the  while  loop  is  assembled." 

DO  YOU  WANT  TO  OPTIMIZE  THE  PROGRAM?*  NIL 
IS  THIS  PLAN  USEFUL  ENOUGH  TO  GENERALIZE?*  T 
IS  THIS  A  PROCEDURE  WITHOUT  SIDE  EFFECTS?*  NIL 

THE  GOAL  (ONTOP  M)  IS  ATTAINABLE  BY  THE  FOLLOWING  PROGRM: 

"The  desired  program  has  been  generated  and  will  now  be  displayed." 

PROCl(M) 

ROBOT  (M);CI  SHOES  );<BOX(B  1  );BOX(B2)i 

COMMENT 

INPUT  ASSERTIONS: 

AT(M  CORNER)  a  AT(B1  L)  a  STACKED(B2  Bl) 

OUTPUT  ASSERTIONS: 

WEARING(M  SHOES)  A  AT(M  L)  A  ONTOP(M); 

COMMENT 

THIS  PROGRAM  RELIES  ON  THE  FOLLOWING  ASSUMPTIONS: 

(DRESS); 

BEGIN 

DRESS(M  SHOES); 

TRAVEUM  CORNER  L); 

STANDON(M  Bl); 

Y1  <-  Bl; 

IF  STACKED(W1  Yl)  THEN 
Z1  ♦-  Wl; 

WHILE  -  ONTOP(M)  DO 
BEGIN 
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STEPUP(MY1  Zl); 

Y1  <-  Zl 

IF  STACKECKW1  Yl)  THEN 
Zl  ♦-  Wl; 

END 

END 

DO  YOU  WANT  TO  DO  STRUCTURED  PROGRAM  DEVELOPMENT?*  T 

TRYING— ((DRESS  M  SHOESXWEARING  M  SHOESXSTAT1.AST)) 

"This  task  triple  consists  of  procedure  name,  goal  and  state." 

DO  YOU  HAVE  ANY  ADVICE?*  T 

♦♦♦ENTERING  ADVICE  SYSTEM*** 

#1*  ADD  PUT-ON 

RULE  TYPE*  PRIMITIVE  PROCEDURE 
RULE  NAME*  PUT-ON(Rl.Ol) 

IS  THIS  AN  ASSUMPTION?*  NIL 
IS  RULE  DIRECTLY  RECURSIVE?*  NIL 
INEQUALITIES  IN  ARGUMENT  POSITIONS*  NIL 
PRECONDITIONS: 

*  ROBOT(Rl)  a  CLOTHES(Ol)  a  F0UND(R1,01); 

POSTCONDITIONS: 

*WEARING(R1,01); 

RULE  TYPE*  PRIMITIVE  PROCEDURE 
RULE  NAME*  FINLKKl ,01  ,L  1 ) 

IS  THIS  AN  ASSUMPTION?*  NIL 
IS  RULE  DIRECTLY  RECURSIVE?*  NIL 
INEQUALITIES  IN  ARGUMENT  POSITIONS*  NIL 
PRECONDITIONS: 

*  ROBOT(Rl)  a  CHAIR(02)  A  AT(02,L1)  A  AT(R1,L1)  a  UNDER(01,02); 
POSTCONDITIONS: 

*  F0UNQ(Rl,01)j 

RULE  TYPE*  NIL 
INITIAL  STATE: 

*  CHAIR(CHAIRl)  a  CHAIR(CHA  IR2)  a  AT(CHAIR1, CORNER) 
a  AT(CHAIR2, CORNER); 

SEMANTIC  PROPERTIES  OF  RELATIONS: 

IS  FOUNLXRl.Ql)  A  FUNCTION  OF  THE  STATE?*  T 
IS  FOUNO(Rl.Ol)  PARTIAL?*  NIL 
ARGUMENT  UNIQUENESS  PROPERTIES*  NIL 


IS  CHAIR(02)  A  FUNCTION  OF  THE  STATE?*  NIL 
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IS  CHAIR<02)  PARTIAL?*  NIL 
ARGUMENT  UNIQUENESS  PROPERTIES*  NIL 

IS  UinIDER<01,02)  A  FUNCTION  OF  THE  STATE?*  T 
IS  Un!D£R(01,02)  PARTIAL?*  T 
ARGUMENT  UNIQUENESS  PROPERTIES*  NIL 

ALGEBRAIC  SIMPLIFICATION?*  NIL 

SUBGOALING  SYSTEM  GENERATED!!! 

"The  Frame  addition  has  now  been  translated." 

«2*  DELETE  DRESS 
#3*  NIL 

"Exit  Advice  system." 


RULES  ENTERED  AND  GOALS  PENDING  IN  CURRENT  SUBGOAL  TREE  PATH: 

— (PUT-ON(FOUND  M  SHOES))FIND 

((FIND  M  SHOES  CORNER)) 

«IF(-UNDER  SHOES  CHAIR1)  THEN  (PROC2  M  SHOES) 

ELSE((FIND  M  SHOES  CORNER))XPUT-ON  M  SHOES)) 

"The  conditional  statement  is  generated  since  it  is  not  Known  where 
the  shoes  are." 

DO  YOU  WANT  TO  OPTIMIZE  THE  PROGRAM?*  NIL 
IS  THIS  PROGRAM  USEFUL  ENOUGH  TO  GENERALIZE?*  T 
IS  THIS  PROCEDURE  WITHOUT  SIDE  EFFECTS?*  NIL 

THE  GOAL  (WEARING  M  SHOES)  IS  ATTAINABLE  BY  THE  FOLLOWING  PROGRAM: 
"This  procedure  is  the  structured  expansion  of  the  non-primitive 
procedure  DRESS  called  in  PROC1." 

DRESS(M  SHOES) 

ROBOT(M);CLOTHES(SHOE$);CHAIR(CHAIRl); 

COMMENT 
INPUT  ASSERTIONS: 

AT(M  CORNER)  a  AT(CHAIR1  CORNER) 

OUTPUT  ASSERTIONS: 

WEARING(M  SHOES)  a  FOUND(M  SHOES)  a  WEARING(M  SHOES); 

COMMENT 

PROC2  ATTEMPTS  TO  ACHIEVE  FOUND(M  SHOES); 

BEGIN 

IF  -UNDER(SHOES  CHAIR1)  THEN 
PROC2(M  SHOES) 

ELSE 

BEGIN 

FIND(M  SHOES  CORNER); 

END 

PUT-ON(M  SHOES) 


W'T" 
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END 

DO  YOU  WANT  TO  DO  CONTINGENCY  PLANNING’*  T 
WHAT  IS  YOUR  PREFERENCE? 

- IF  NONE  TYPE  NIL*  NIL 

TRYING— (PROC2  (FOUND  M  SHOESXSTAT2.CST)) 

The  contingency  task  triple  consists  of  procedure  name,  goal  and  state.“ 

DO  YOU  HAVE  ANY  ADVICE?*  NIL 

RU  HND  AN°  G°ALS  PEN0ING  CURRENT  SUBGOAL  TREE  PATH: 

((FIND  M  SHOES  CORNER)) 

DO  YOU  WANT  TO  OPTIMIZE  THIS  PROGRAM?*  NIL 
13  THIS  PROGRAM  USEFUL  ENOUGH  TQ  GENERALIZE?*  T 
IS  THIS  PROCEDURE  WITHOUT  SIDE  EFFECTS?*  NIL 

THc  GOAL  FOUNLXM  SHOES)  IS  ATTAINABLE  BY  THE  FOLLOWING  PROGRAM: 

PROC2(M  SHOES) 

HOBOT(M):CHAIR(CHAIR2); 

COMMENT 
INPUT  ASSERTIONS: 

AT(CHAIR2  CORNER)  a  AT(M  CORNER) 

OUTPUT  ASSERTIONS: 

FOUNLXM  SHOES); 

COMMENT 

PROC3  ATTEMPTS  TO  ACHIEVE  FOUND(M  SHOES); 

BEGIN 

IF  -UNDER(SHOE3  CHAIR2)  THEN 
PkOC3(M  SHOES) 

ELSE 

BEGIN 

FIND(M  SHOES  CORNER); 

END 

ENJ 

DO  YOU  WANT  TO  DO  CONTINGENCY  PLANNING’*  NIL 
DO  YOU  WANT  TO  CONTINUE  FROM  THE  CUKRENT  STATE?*  NIL 
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